Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

121–130 of 369 posts

Re: Writing Python like it's Rust

#121
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 have extensive experience of MyPy and Pyright, even going so far as to try to fix a but in MyPy (I couldn't do it; the code is too much of a legacy undocumented mess).

Pyright is much much better. If you're starting a new project or work with people who understand the value of type hints and want to actually fix them (ha yeah right) it's a no brainer. It's also the default in VSCode which is nice. Oh and they guy that maintains it is a bug fixing machine.

The only reason you should consider MyPy is if you're adding types to a big existing project or you're working with people that don't get it. MyPy has way more "eh whatever" options so it doesn't give you a barrage of errors when you run it for the first time.

But other than that you should use Pyright. No contest.

Re: Writing Python like it's Rust

#122

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

Everything you just said is true for Typescript, as you can set it up as strict or as forgiving as you like, and writing one off scripts for node is just as easy as for Python. But unlike Python, it has a great type system.

Typescript is way way better for one off scripts than Python - using Deno you can have single scripts that can actually import third party and first party dependencies reliably.

Neither of those work well in Python. To import third party libraries you need to use Pipenv or Poetry or one of the many other half baked options.

Importing first party dependencies (e.g. code from another file) is also a nightmare because the path searching strategy `import` uses is insane. It can even import different code depending on how you run Python!

Re: Writing Python like it's Rust

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

> The whole point of Python is the duck typing.

Duck typing implies that "Should this work?" has one true answer: "Did it work?" I am at work to work, not to play guess-and-check with upstream libraries.

Re: Writing Python like it's Rust

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

The article mentions connection, so it’s the connection the DB rather than the data. Ie the thing you get after you open the socket.

Re: Writing Python like it's Rust

#125
I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been.

Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would just be ‘class Foo’ in almost any other language. I never have this problem C++/C#/TypeScript. I’d love to see type hinted Python look more like TypeScript.

I use Python every day and I like it less and less as it gets more of the features I want/need to use. I want types, I want generics, I want abstract classes, I want enums, I want interfaces. But I don’t want to have to import all of those features from modules when they should be built into the language itself.. When they’re built into the syntax of practically every other language that supports them.

When was the last time you saw a `Protocol` in the wild? Just add interfaces.

Teaching Python to a new developer is a ridiculous experience. There are just too many, usually half-baked, ways of doing things. Even this article, which does a great job going over some of Python’s newer/more advanced features, doesn’t use the latest version of the syntax or the generic versions of most types.

If I didn’t have such a massive investment in Python I would have moved to Rust by now. And don’t me wrong, I love Python, I want to use it. I just wish it would stop eating its tail.

Let’s just do a Python 4. Even if it means another decade long 2/3 adoption foot dragging.

Re: Writing Python like it's Rust

#126

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been. Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would j…

Personally, I switched to Go.

Re: Writing Python like it's Rust

#127

Earlier quoted context omitted.

> the fields I need tools for are vast, and it's the only one that I'm pretty sure will handle a problem decently in all it's various forms Whilst I agree with this stance to some extent, we should be clear that Python is not in fact the panacea you've made it out to be here. It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clums…

> the panacea you've made it out to be here. This is misreading my comment, at best. > It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt…

[deleted]

Re: Writing Python like it's Rust

#128
post #126

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been. Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would j…

Personally, I switched to Go.

I've been thinking about getting into go - do you mind giving some pros/cons?

Re: Writing Python like it's Rust

#130
post #95

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…

Another difference you might be surprised by is that the .NET tooling by default collects various data from your system and sends it to Microsoft [1]. If you want to avoid this (and still want to use .NET) you'll have to make sure that the environment variable DOTNET_CLI_TELEMETRY_OPTOUT is set to 1 in all contexts before touching anything. [1] https://github.com/dotnet/sdk/issues/6145

> DOTNET_CLI_TELEMETRY_OPTOUT

I didn't know about this. I wonder how that sits legally with local data protection rules (EU).

Post reply on HN