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

51–60 of 369 posts

Re: Writing Python like it's Rust

#51

Post by mgaunard »

8589934591 wrote: post #31
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.

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

I'm pretty sure any serious company uses C++ for the code that matters, and Python for orchestration (assuming no high scalability requirements), GUI, offline data analysis and calibration, etc.

Re: Writing Python like it's Rust

#52

Post by v21 »

8589934591 wrote: post #31
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.

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

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

Yep - or it's the standard for some tasks & the important thing is being able to use the ecosystem of external packages that everyone else uses. In this case, the author is working on AI & computer vision, for which everyone else uses Python. Python could be a much worse language than it is and using Python would still be the right choice in this scenario.

Re: Writing Python like it's Rust

#53

Post by Kwpolska »

quietbritishjim wrote: post #15

> Dataclasses instead of tuples or dictionaries The point is good in general, but it's still perfectly possible to use tuples and get all the field name and typing benefits: just use typed named tuples [1]. Unfortunately this is buried in the typing module. I couldn't even find it in the table if contents, and I knew what I was specifically looking for. https://docs.python.org/3/library/typing.html#typing.NamedTu...

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

Just use an actual class, not a class pretending to be a tuple sometimes.

Re: Writing Python like it's Rust

#54

Post by quietbritishjim »

raverbashing wrote: post #19
quietbritishjim wrote: post #15

> Dataclasses instead of tuples or dictionaries The point is good in general, but it's still perfectly possible to use tuples and get all the field name and typing benefits: just use typed named tuples [1]. Unfortunately this is buried in the typing module. I couldn't even find it in the table if contents, and I knew what I was specifically looking for. https://docs.python.org/3/library/typing.html#typing.NamedTu...

> typed banned tuples I think you mean typed named tuples

Oops, thanks! Fixed now

Re: Writing Python like it's Rust

#55

Post by iudqnolq »

mgaunard wrote: post #48
linkdd wrote: post #32

Earlier quoted context omitted.

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

I also do not consider websites or smartphone apps to be serious software, despite the huge amount of work that happens to be done there. You know the rule, 99% of everything is crud.

I find it hard to understand how you can believe something like Dropbox isn't "serious production" just because it involves websites and apps.

Re: Writing Python like it's Rust

#56

Post by mgaunard »

v21 wrote: post #52
8589934591 wrote: post #31

Earlier quoted context omitted.

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

> 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). Yep - or it's the standard for some tasks & the important thing is being able to use the ecosystem of external packages that everyone else uses. In this case, the aut…

In computer vision, you use Python for prototyping and research. It of course gets rewritten if it's to be actually used, think for example of the guidance system in a car, plane, or weapon.

It's pretty much the same for AI, except that there is an increasing trend in AI of it being used by people that do not have the skills to do the productionization.

Re: Writing Python like it's Rust

#57

Post by quietbritishjim »

Kwpolska wrote: post #53
quietbritishjim wrote: post #15

> Dataclasses instead of tuples or dictionaries The point is good in general, but it's still perfectly possible to use tuples and get all the field name and typing benefits: just use typed named tuples [1]. Unfortunately this is buried in the typing module. I couldn't even find it in the table if contents, and I knew what I was specifically looking for. https://docs.python.org/3/library/typing.html#typing.NamedTu...

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…

I wasn't saying that you always ought to use a named tuple instead of a dataclass. Only that, if you do want a tuple, that option is still available.

Personally, I would use a tuple if I want something immutable. I realise you can do that with dataclasses by setting frozen=True but it feels a little over engineered to me.

Re: Writing Python like it's Rust

#58

Post by csunbird »

Kwpolska wrote: post #53
quietbritishjim wrote: post #15

> Dataclasses instead of tuples or dictionaries The point is good in general, but it's still perfectly possible to use tuples and get all the field name and typing benefits: just use typed named tuples [1]. Unfortunately this is buried in the typing module. I couldn't even find it in the table if contents, and I knew what I was specifically looking for. https://docs.python.org/3/library/typing.html#typing.NamedTu...

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 .

Re: Writing Python like it's Rust

#59

Post by JodieBenitez »

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.

Re: Writing Python like it's Rust

#60

Post by tejinderss »

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 can do almost all the dynamics things that I can do in Python with C#, but in a type safe way.

If you like flexibility with a good type system, give Typescript a try, its miles ahead of mypy and its designed by same person who’s behind C#.

Post reply on HN