Why would you ever want a == b to not return a bool??

EDIT: Yes, I understand that you can do element-wise equality checks on numpy arrays now

Statically typed languages provide the determinism necessary to efficiently anchor probabalistic coding agents.

You can throw as much type checking at dynamic languages after the fact, but youre just going to burn energy (and tokens) doing what another language gets 'for free'.

There are two types of tests: those that test against the public API, and those that test internal codes with various mocks and fakes. I think the vast majority of unit tests is the latter one, in which case the suggestion does not really make sense.

Unfortunately for Django apps switching to any alternative leads to the dreaded “wall of errors” issue. If anyone got to work this out in the past, I’d gladly take advices.

RightTyper is a Python tool that automatically generates type annotations for your code. It monitors your program as it runs and records the types of function arguments, return values, local variables, and class fields — with only about 25% runtime overhead. This makes it easy to integrate into your existing tests and development workflow, and lets a type checker like mypy catch type mismatches in your code.

Python's type checking ecosystem truly is a mess.

I see the appeal for type-checking and yeah it has caught many bugs. But the language is quickly running blindly to the worst of all worlds in regards to typing.

1. You have to exhaustively write types in many cases where they can be obviously inferred.

2. The type checking is just a lint step. i.e. we are still paying for the duck typed typing system.

3. We no longer get to use the duck typed typing system making a lot of generic code require obscure annotation incantations to pass the lint check while it's correct python code.

My ideal typing system would be around constraints introduced by the code and completely inferred unless the user wants to tighten the constraints. i.e

Instead of

  def foo(a: int, b: int) -> int:
    return a + b

  def foo(a, b):
    return a + b

It would tell you that there is no + operator for int and dictionary that is required by the foo function.

My ideal typing system would allow you to constraint the types as well like so

  def foo(a: int, b: int):
    return a + b

"Type checkers should narrow the types of expressions in certain contexts. This behavior is currently largely unspecified."

Have fun.

[1] https://typing.python.org/en/latest/spec/narrowing.html#type...

Take, for example, PHP… look at the features released in the last 6 or so years, starting with PHP 7, and how mature the language has become.

With the advance of AI-assisted programming, I feel like Python is always a bad choice.

> The type checking that matters most (and why you've probably got it backwards)

Honestly, I don’t care if the author got some AI help. But that click-bait style is ubiquitous and obnoxious.

But PyCharm's built-in type checker is far and away the best that I've used with proper type inference through multiple class inheritance hoops.

The blog entry fits into ruby too, to some extent; while the situation is nowhear near as bad as in python, you have the same question-marks why types suddenly emerge out of nowhere. Almost ... almost as if some people have a specific agenda, and try to pull through with it.

Well, there you have it - the type-addicted people are ruining python.

Strongly typed, compiled languages have never been easier to use, and agents reap huge benefits from the tight feedback loop that the compiler provides. Moreover the benefits of the Python ecosystem are less significant today than anytime in the past 20 years. Need something that's only available in Python? Just point some agents at it and you can port it.