@askonomm @zenforyen @cazabon @kevin @ado

Maybe our code base is not large enought😉.

But seriously, I think the reasons are more fundamental.

For example, static type checkers would probably run away in panic from our code base, because we have many situations of indirect function calls manipulating *args.

For example, a cache system based on a #python function based dependency graph, where many function calls are indirect using second order functions and adding parameters dynamically.

@folkerschamel @askonomm @cazabon @kevin @ado I think you're fighting a strawman.

It goes without saying that either you decide to "work with" a type checker, and adopt a #python style to maximize code it can check, or you don't.

Yes, you can't throw pyright or mypy at an arbitrary dynamic wild west code base, and hope it can help you, it can't do magic. So it's a choice you ideally did at the start.

I personally prefer having that additional mechanical pair-programmer in my team.

@zenforyen @askonomm @cazabon @kevin @ado

You can squeeze a round piece into a squared hole. But the solution for a programming problem should reflect the type of problem. Many problems are deeply inherently dynamically typed. I think we have many in our code base.

And when wanting static type checking, then I think it's better to use a static typed language like #java, #cpp or #golang instead of fake static typing aka type hints and misuse #python for something it is not designed for.

@folkerschamel @askonomm @cazabon @kevin @ado If I had the choice, I would not use python for many things.

But there are factors such as library ecosystem and also accessibility. Where I work, still the chance is much higher someone will be able to maintain the type-hinted python code than if I wrote it in a statically typed language.

@zenforyen @askonomm @cazabon @kevin @ado

How would you express something like the following architecture in #mypy friendly #python code or even better in different programming languages like #cpp, #java, #golang etc?

(One part of our software is fundamentally based on countless such calls all over the place.)

def f(smart_evaluator, a, b):
...

def g(...):
x = smart_evaluator.exec(f, someting_extra, a, b)

Of course it is possible, but the question is how natural, easy and elegant it is.

@zenforyen @askonomm @cazabon @kevin @ado

"Where I work, still the chance is much higher someone will be able to maintain the type-hinted python code than if I wrote it in a statically typed language."

For interest: why?

Edit: If I think about it, it sounds like you would prefer a statically typed programming language, but you are forced to use #python against your will, so you are imposing a statically typed programming style onto (poor) #python by using type hints?😉

@folkerschamel @zenforyen @askonomm @cazabon @kevin @ado For me, the biggest advantage of type hinting, especially for function parameters and return values is that my Editor/IDE (I use VS Code) works much better this way. Untyped parameters usually don't show me methods and properties, which means I have to go to the docs again if I haven't it memorized.

@sesenion @zenforyen @askonomm @cazabon @kevin @ado

Probably depends on the IDE, but #eclipse and #pydev seems to work reasonable well.

Except of course refactoring (renaming methods, classes) doesn't work well with #python.