Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

11–20 of 369 posts

Re: Writing Python like it's Rust

#11

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 think it depends™ – when you know for sure there will just be one place to call this from, your approach is totally okay and wrapping it in seperate types would be overkill.

The seperate types will come in handy, once you end up using that client object throughout the codebase and you are not sure anymore who is connected, who is authenticated and so on. By pushing that onto the type system you can make less mistakes.

Re: Writing Python like it's Rust

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

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.

Re: Writing Python like it's Rust

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

Replace real with different and I'll fully agree with you.

Re: Writing Python like it's Rust

#14

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…

> Perhaps I have not worked in a large code bases to understand the problems

Basically, yes.

In a large codebase the steps in your example could well be separated by thousands of lines of code, with much branching, or perhaps complicated inheritance hierarchies.

In that case leveraging type hints to avoid logic errors can avoid a lot of hard-to-spot bugs

Re: Writing Python like it's Rust

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

Re: Writing Python like it's Rust

#16
post #3

> Is records a list, a dict or a database connection? Records is a list of record items. It’s a plural. If it was a dict, it would be recordByID. If it was a database connection it would be called connection. Strict typing is good, and you should definitely use it, but you should still have good names.

Most good databases actually store data per column.

So you'd have a list of batches, each batch being a dict of string to list of T.

Re: Writing Python like it's Rust

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

A senior Python Dev knows the real answer is to stick 'assert's around the place sporadically and start using optional arguments like 'failonerror=False'

Realistically I think it depends what you are doing. For some code type hinting is useful. Some code it is not.

Re: Writing Python like it's Rust

#18

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…

Depends on what you do with the Client. If you have a complicated application and pass the Client around between different functions then maybe you would need to check every time whether the client is connected and authenticated before sending a message. If the function only accepts an authenticated client, then the type checker will complain. You could also notice the problem in a unit test, but it may be hard to represent all possible states.

In simpler situations where every time you just do the sequence you probably would want to combine some of these calls anyway.

Re: Writing Python like it's Rust

#19

> 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

Re: Writing Python like it's Rust

#20

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…

The idea is that you'll come back to this code years from now. You'll have your head full of other projects and code bases by then. You will have only a faint idea of what that old code of yours is doing and you won't remember how and why. Anything that can help you to understand your code is good.

The same reasoning applies to other developers working on your code next month. However if your Python turns out to be very far from idiomatic Python you're not helping them the slightest. You're doing harm to the team and to your career, unless everybody agree to make it the company standard and you have your back covered.

Post reply on HN