Type hints aren't useless - you can type check your code before you run it (and they make your code more readable).

> What I would love is a mode in python where instead of duck typing everything, its statically typed, unless I do a magical incantation.

You can do this with mypy, you can set it to require types everywhere.

You get 99% of what you want by just using Python with Mypy (as a pre-commit hook, editor plugin, and/or CI step). Python has static type checking; it just comes in the form of Mypy instead of being baked into the Python executable.

So I work with a reasonably well typed codebase, type hints are great for documentation. Especially as most people where I work fear writing any kind reason _why_ they wrote what they wrote.

But it don't help with stuff that gets transmuted in flight. Granted with pydactic is your friend here, but thats a lot of work to backport.

basically I want c#'s typing system with python's syntax.

> One thing that always bugged me was the lack of "strict" mode (see perl)

What Perl has as "strict" mode, Python just has by default all the time. The typing is dynamic but strong, it will complain about unbound variables instead of silently creating them, scoping, while not ideal, is sane out of the box.

What Python doesn't have is taint mode, but that is quirky and fragile as hell in Perl as well, and more of a nuisance nowadays than an actual aid.

> The typing is dynamic but strong, it will complain about unbound variables instead of silently creating them

Are you sure about that?

    def example(x):
      result = 123
      if x == 456:
        reslut = 789 # undetected typo
      return result

In Perl, this throws an error at compile time:

    use 5.036;
    sub example ($x) {
      my $result = 123;
      if ($x == 456) {
        $reslut = 789; # <-- Global symbol "$reslut" requires explicit package name
      }
      return $result;
    }

yes! exactly this. Now obviously people would say "just use a linter" but its not actually as reliable as a builtin.

Moreover, people who have dyslexia are not always able to spot stuff like this.

Every python linter or code quality tool has been able to detect unused local variables like this since at least the year of our lord, 1841.

You don’t need this baked into the language.

So what? This is just one class of the mistakes you can make. For the sake of argument, if you do have both "$result" and "$reslut" (they don't need to be named like this, of course, just continuing your example) with very different purposes, and you use the wrong one, the result is ... just as wrong.

I think all popular linters for Python catch the mistake you have shown since a decade or so. You create a variable and then don't use it.

On the other hand, I've been screwed over by wild list context suddenly appearing and swallowing my undefs (that I needed to be there) countless times. To this, Perl doesn't have a remedy. It won't even warn me that a function returned an undef but the list context squashed it into nothingness. This causes, for example, off-by-one errors that lead to creation of malformed hashes which sometimes may look almost right except the data is corrupted now. Even worse, two undefs instead of one will silence the warning about odd number of elements forming a hash, and that hash will be just as corrupted.

Perl weenies very much like to brag about crutches their language invented to bravely overcome the problems it itself has created, and it prevents them from realizing how limited those crutches are.

I'm not saying that Perl is perfect. Far from it.

But saying that Python "will complain about unbound variables instead of silently creating them" is simply incorrect. One of the defining characteristics of Python's variable scope is that assigning to a name always creates it in the current scope; there's no other way to declare a variable. And that's all I'm trying to demonstrate here.

The act of assigning is creating a variable; the act of using it will complain about an unbound variable.

Perl in non-strict mode, PHP last I touched it, Bourne-style shells will just go “yeah, whatever, here’s an empty string”.

perl is not a perfect language. nobody should be claiming that.

They way function args are define is just pure passive aggression (oh so you _want_ people to name args properly eh? go on, you validate the arg name. Go on, fiddle with the hash like that). However we should be able to look at any language and pull out its interesting/useful features.

I loved perl's can do attitude. You wanna do that to an array? sure. it'd going to end bad, but here you go kid, have at it.

Is that good for everyone? no.

does it mean that you need to be hilariously disciplined to make readable code? very yes.

Can one make readable and maintainable code in perl? hell yes. I've worked on some wonderfully maintainable perl code.

I've also worked on a lot of shite. But then the same goes for python. I transmute research code into production, and let me tell you, there are some "perls" of programmers right there.