Writing Python like Rust (2020)

Thousands of files all become filled with very obvious bugs once you enable a basic type checker, which then helps brand Typescript as "too much effort" by those who normally write Javascript because now they need to deal with their buggy code. Luckily you can just explicitly cast all of your types without checking and hope that nobody notices!

When you ask people to get their typing right, someone will use buzzwords like "rapid prototyping" and remind you that features are more important than fixing the existing product as long as nobody complains about the bugs, and that's that. Also, Typescript is hard, apparently.

Untyped legacy code sucks. It's one of the reasons I detest working with languages like Javascript, Python, and PHP. At least Python and PHP have types these days, making Javascript objectively inferior.

It makes writing the happy path slower, but is writing the happy path _programming?_

By the time you have a program which is complete and (at least mostly) bug free, the static typing has saved you hundreds of hours.

To this day, I'm baffled by the dynamic language folks who cannot get their head around how strictness/rigor (via a good expressive type system) actually makes maintenance easier and more importantly: cheaper.

[1] https://github.com/inducer/pudb

I wish more people started using Beartype, it makes Python bearable

They just don't know it, and the people hiring them don't either.

It's not a new phenomenon, we got the same when Java arrived, then PHP, etc.

Every time something makes things easier, you get a wave of beginners set to create things they are not qualified to do. And because you now need software for everything, leaders also get into positions where are not qualify to make some decisions about it. You pair unqualified leaders with unqualified devs, and you get this.

And it's now easier than ever to be in this position, also you are more pressured than ever to get into this position.

I've worked on plenty of big Python systems myself, it's not the tech per se (it has the usual pros and cons game like every language), but Python is the language used "when you don't know programming".

Which is ironic, because when I started to use it in Python 2.4, only passionate devs used it because it was niche, and we had the opposite effect.

A static checker with global type inference could be a middle ground. Pylance/Pyright already does that for most VS Code users. A more advanced form of this could track types that are too tedious for humans, like list emptiness, bounds, string alphabet, functions that can raise exceptions, idempotence, side effects, etc.

Those types can then be shown in the IDE, according to user preference, like docs or source control metadata.

I have a feeling that with enough caching this could be done with ok performance, but I hear that useful error reporting is an unsolved problem.

Might seem like nitpicking, but the 'probability of a bug being triggered in the future' is an important metric for figuring out if large scale refactorings are actually worth the risk of introducing new bugs.

Disclaimer: I'm coming from the static typing hemisphere, but adding type information to a codebase that was originally written with runtime-duck-typing in mind sounds like it might actually make maintainability of the code worse - that's at least my experience after trying to do exactly this in a medium-sized Python codebase - some of the 'typings' ended up so complex and weird that they completely dominated the code and turned what was very simple code at the beginning into an unreadable mess (looking almost like C++ template code). I eventually rolled back the changes. Basically, if I wanted a statically typed language, I wouldn't have chosen Python in the first place for this type of project.

Also, imagine how much more productive you would've been if you instead of doing what you are doing you'd do something worthwhile, like, design the program or organize the testing better.

I've heard so many nonsense claims like yours both in proprietary projects and in open-source ones, and not a single time did the code base became better. In most cases a small(-er) pile of garbage became a bigger pile of garbage.

Are there any tools for that? If not could one be made? Sounds almost like an advanced linter.

You can break almost any python code by passing in the wrong type. The code throwing runtime type-errors IS the type checking.

The danger is only if the code happily operates on the wrong types and returns incorrect results.

When I advocated for the importance of static typing for software robustness the response I got from many other industry people I knew was that this was the job of intensive unit testing. That the supposed loss of rapid turnaround that came with static types wasn't worth it, and that test-first-design solved this problem.

Now Typescript and Rust are common place, and we have Pythonistas annotating their programs with types. I'm happy, but maybe a bit bitter about the past :-)

Handling errors locally is difficult to do with exception handling because it's impossible to tell what errors a function might produce (if any!). It's also more verbose (especially compared to Rust) which just makes it annoying.

Checked exceptions are the usual answer to this but they're so tedious most people don't bother with them. C++ even dropped support for them from the language.

Rust's error handling is much better than exceptions in almost every way.

Only bubble up if your handling consists of reraising anyway and no business logic can be applied (which might be the majority of cases).

If you write typed python code that lets you avoid this while writing the bad code at the beginning itself, that’s a win. Actual runtime errors caused due to invalid user input should of course throw appropriate exceptions deep in the code and bubble up and be handled in middleware.

Exceptions are obviously great for bubbling up, but just awful for handling locally. I don't know what it is: maybe it's the horrible try/catch control flow that breaks everything up, or the fact that all functions can "return" exceptions apart from the ones in the signature (if any), so you're never quite sure what happens or what to do.

So, for a Django app is it better to use their built-in middleware framework or something third-party that sits outside of Django?

https://docs.djangoproject.com/en/4.2/topics/http/middleware...

This is why the try: block should never contain more than one single line, with the except block(s) limited only to the errors that can be expected from that line and that you explicitly want to handle at that point. Trying multiple lines and handling generic levels is a perfect way to get errors that are difficult to track.

> In a weakly typed language a compiler / interpreter will sometimes change the type of a variable

Well,

    a = 1
    a = "a"
    a = [1, a]

Even if you take the "dynamic but strong" argument, it only holds for a few specific operations. A function like this cannot be considered strongly typed:

    def f(x, y):
        return x + y

People have been desperately wanting to claim that Python has strong typing, but it not having weak typing doesn't make it strong. They're not binary opposites.

Not to mention the intentionally(!) thrown exceptions for iterators. In my book, exceptions are goto by another name.

That is never implied. See the first example in the article.

The thing that drives me crazy about Python typing is that I need to import stuff to make full use of the type system. Like I get that the typing is option because that would be a huge language overhaul, but it feels weird that so many tools get hidden inside libraries (standing or otherwise).

Then you can appreciate which tool to use and when, rather than getting distracted by strange religious notions about how "this language is better than that one". It also prevents you from forcing conventions the language doesn't align well with, and that if you're going to _try_ to do so - you should do so gradually and very carefully.

Other aspects of a language can matter more than the types. Python, for example, was a well constructed language in many ways that make up for much of its disadvantage on the typing side.

Many commonly used statically typed languages have poor type systems. They will both fail to detect some important errors (like null pointers) and get in the way when writing more generic code.

The Elixir ecosystem is top notch. Phoenix, Ecto, Livebook, Mix, Hex, Nx, Axon, Scholar, Explorer, Broadway, and Rustler are libraries and tools that make it hard to use anything else even when the language doesn't have types. I never enjoyed programming in a language more than Elixir.

Tho, they are currently are in the process of researching a type system for Elixir.

FWIW, there are definitely ways to do it "right" in languages like Python, but it's a slightly different approach to dev than in other languages, so people create a mess if they don't shift, or if they are just untrained/sloppy/lazy/whatever. But when you have a team of people doing it right, it's really quite nice, even as the codebase grows large.

But if even just one person on the team can't be trusted to do it that way, you're probably better off in some other language.

In dynamic languages the typing is just moved to the test suite. We can see that with the way type hints are enforced in Python and Ruby - by running a program that takes those hints and essentially runs a bunch of tests.

If you look at the code of Terraform, for example, you'll see that it spends a lot of time trying to get around the limitations of Go typing.

The rise of dynamic languages in the early 2000s was a direct result of the perceived limitations of the type systems of Java, C++, etc. and the ability to use a different way of constraining code (Test driven development, behaviour driven development).

Now it is swinging back the other way with the implementation of more flexible type systems.

Before too long the limitations of those type systems will start to grate and the pendulum will swing back to dynamic languages again - based upon some new innovations there.

Get used to the back and forth in IT. The static/dynamic cycle is but one of many. (Centralisation/decentralisation is the other main one). You'll find lots of work in IT is reimplementing existing stuff in the current fashionable paradigm.

E.g. I wrote c# and Python for a living. Especially in the mid 2010s python was much better for the Microservices I wrote because they are so small that you could unit test them exhaustively. The lack of ceremony and small domain model made development super easy. C# just felt clunky and limiting. You spend lots of time wrangling types which could have been figured out by the compiler.

Nowadays c# has gotten a lot of features that reduce type ceremony and extend their usefulness (nuallibility checks, better tuples etc) so it feels much more ergonomic (unlike java where the culture still goes off on needless verbosity) . Python also got types which I use a lot, it helps to document it for other developers, ides and spot bugs.

The maintainer is not ready for a paradigm shift because they will not own your program in perpetuity. Even you yourself ran away and abandoned it, so how can you expect someone else to love it more? No, the maintainer has a limited time and attention span to work on a specific bug or feature, and your code is either maintainable or it's not.

This however does not stop people from trying to use their one preferred language fer beyond it's focus area.

IMO one of the major turning points in a developers career is when they learn that finding the right tool for the problem is always the game you are playing. But this almost always takes learning this lesson the hard way by pushing a language one know very well past its breakpoint.

(You can also do this with ABCs by writing custom __subclasscheck__ and __instancecheck__ functions, but those can't be statically checked, they only work at runtime)

AFAIK protocols actually use ABCs internally(?) Just in a more constrained form that static type checkers can understand.