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

131–140 of 369 posts

Re: Writing Python like it's Rust

#131

Post by nwatson »

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

A good IDE like PyCharm makes it pretty simple, will offer to write all the import statements for you when you reference something that's new to the file you're working on. I'm taking a pretty decent course on Udemy right now, but the instructor said they didn't see the value in PyCharm and they're writing all this extra boilerplate by hand in VSCode.

I started using copilot recently and that's accelerated the process even more.

Re: Writing Python like it's Rust

#132

Post by kps »

IshKebab wrote: post #121
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 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 t…

I'm on the other end of the spectrum — I only write Python occasionally for smallish utility tools, just a step above shell scripts — so I'll give my input as someone relatively new to typed Python. I recently industrialized (to use the terminology from other comments here) a couple things that I'd originally done in quick-and-dirty Python 2 over a decade ago. My experience was that mypy had a handful of false positives, and pyright had none. Pyright also found one comparatively subtle mismatch that mypy didn't, although its error message in that case was incomprehensible to me.

(I also used pylint and pytest+coverage.py; interested whether there are better choices for next time.)

Re: Writing Python like it's Rust

#133

Post by miiiiiike »

nwatson wrote: post #131
miiiiiike wrote: post #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 j…

A good IDE like PyCharm makes it pretty simple, will offer to write all the import statements for you when you reference something that's new to the file you're working on. I'm taking a pretty decent course on Udemy right now, but the instructor said they didn't see the value in PyCharm and they're writing all this extra boilerplate by hand in VSCode. I started using copilot recently and that's accelerated the proces…

These are not complicated tasks that should require a plugin or an AI assistant to make bearable. Just add the syntax to the language.

Re: Writing Python like it's Rust

#134

Post by [deleted] »

movedx wrote: post #126
miiiiiike wrote: post #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 j…

Personally, I switched to Go.

[deleted]

Re: Writing Python like it's Rust

#135

Post by tored »

Yoric wrote: post #100
BiteCode_dev wrote: post #76

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…

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

I think you have to grade code in your project, i.e not every piece of code has the same value, high value => more strict, low value => less strict.

Less strict code is something that you can throw away and rewrite without too much effort.

This has the implication that you have bulkheads (like in a ship) to separate high value and low value code, thus you have to avoid code that is toxic (i.e magic) that spreads between them, e.g. ORM entities.

When using the type system correctly you don't need 100% coverage, now I'm not a Python programmer so I don't how feasible that is with that type system, but in PHP I use the type system extensible and I don't write that many tests anymore, except for legacy code or when I need to test something specific, like an algorithm. By using the type system you can catch most programmer errors, and combine that with routinely throwing exceptions for any unwanted state, you will detect most bugs.

The way unit testing has been interpreted and implemented it has become more of a nuisance than a help in fast moving projects. Usually what happens is that the team refactors some unit and then multiple test breaks and then time needs to be spent rewriting these test, but what that means is that the tests were actually useless after they where committed if you can change them as you like, when you change a test you are no longer testing the same thing.

Thus tests can also can be graded, from high value tests, i.e stable, and low value tests. Depending how you organize your code, high value tests will usually test a larger set of functionality in one run, like a system (or integration) test from call to finish, these should never change regardless of much you refactor. High level tests should only change when your business logic changes.

Low value test typically involves a lot of mocking and stubbing, those are pretty much pointless to commit after you implemented your unit. Too much mocking and stubbing is code smell.

Re: Writing Python like it's Rust

#136

Post by synergy20 »

rust is great indeed, meanwhile it's hard to learn.

hard to learn language typically can not become very popular(measured by market share) because its framework, tools, libraries,etc will be limited no matter how great the language itself is, and that's a big problem.

It will compete with c++ and c for system programming, it's a hard but it is making inroads gradually, it will take a few decades to replace some core pieces of the fundamental code base(linux kernel, openssl,etc).

out of the system programming field, we have Javascript for the web, Go for the cloud, python for AI and ML, C++ for gaming, C for embedded, etc. It will be very challenge for Rust to do well in all these fields.

unless it's safe AND beginner friendly(easy to use and safe to use, which it is not) that is.

I spent sometime to seriously learn Rust, eventually came back to modern c++. The good thing is that all modern languages are learning from each other, so, in the long term, maybe language itself won't matter that much.

Still, it must have both, easy to use and safe to use, for me, python has the former, rust has the latter, none has both.

Re: Writing Python like it's Rust

#137

Post by fermigier »

Python is still my favourite language, 25+ years after starting using it professionally. Yes, it has become vastly more complex, but its core principles of readability, simplicity, and explicitness continue to make it a versatile and powerful language for both beginners and seasoned developers.

And I personally welcome "recent" additions to the language (gradual typing, pattern-matching, asyncio) as they reflect Python's (and its community's) ability to adapt and evolve, remaining relevant in a rapidly changing technological landscape.

Re: Writing Python like it's Rust

#138

Post by sidlls »

Sosh101 wrote: post #128
movedx wrote: post #126

Earlier quoted context omitted.

Personally, I switched to Go.

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

Some pros:

* Go is "simple" (the language has a "small surface area", if you will)

* Go has a broad and deep standard library that is generally well-documented

* Go comes with a reasonably good general-purpose build tool (it builds, formats code for you, runs tests, etc.)

Some cons:

* Go's structural subtyping is a pretty terrible approach to handling the problem it's meant to solve. It's not quite as bad as a runtime failure when a 'type' doesn't implement a method (since that would be caught at compile time in Go), but it leads to what I consider an abusive over-reliance on ad-hoc interfaces that just get in the way of understanding the code (runtime or test code)

* Go's error handling method is inefficient and generally awful. I'm not talking about the verbosity (it's a relatively small issue, in my opinion), I'm talking about that in Go errors are just strings with a gross, inefficient library and system for adding context

* Go's generics implementation is, to put it mildly, inadequate; doing anything mildly interesting with it will be a cumbersome chore

* Go's handling of dependencies...leaves something to be desired

Re: Writing Python like it's Rust

#139

Post by 0xCAP »

IshKebab wrote: post #122
golergka wrote: post #90

Earlier quoted context omitted.

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

Absolutely agree. I've been writing Typescript for years for work, but I constantly try and explore other languages. The only language I'm never 100% sure how to handle in terms of importing both local and third party code is Python. Virtualenvs are a joke, and version management is terrible. Local imports don't make sense too.

Re: Writing Python like it's Rust

#140

Post by mejutoco »

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

A typical pain point where type hinting fails in Python is with list of some types, it can't be enforced by the language without more checks. For example, you can't do: if isinstance(x, list[int]) though it would be super useful

You need to use mypy or similar to not check it at runtime:

    els: List[int]
To test it at runtime you can use typeguard s @typechecked annotation. For convenience you can also use Pydantic.
Post reply on HN