@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.

@folkerschamel @zenforyen @askonomm @cazabon @kevin @ado Use typing.ParamSpec and typing.Concatenate.

T = t.TypeVar("T")
P = t.ParamSpec("P")

class SmartEvaluator:
def exec(
self,
func: t.Callable[t.Concatenate[SmartEvaluator, P], T],
something_extra: int,
*args: P.args,
**kwargs: P.kwargs
) -> T:
return func(self, *args, **kwargs)

https://mypy-play.net/?mypy=latest&python=3.11&gist=d3eb03d5b02f194b626aed9021139a55

@bk1e @zenforyen @askonomm @cazabon @kevin @ado

That's cool, didn't know that, thanks!

It seems to me that it works if type variables are used in the same function declaration (your SmartEvaluator.exec) or scope-related function declarations (sample in https://docs.python.org/3/library/typing.html#typing.ParamSpec).

Therefore, am I correct that this solution doesn't work for the some_method_of_my_object situation described in https://mastodon.social/@folkerschamel/110881898235959069?

@folkerschamel @zenforyen @askonomm @cazabon @kevin @ado I think your other situation is similar to the `futures` API. The returned object `w` can have a generic type with type parameters that encode additional types, such as the result type. In your case, this would also include the parameter spec.

See https://github.com/python/typeshed/blob/main/stdlib/concurrent/futures/_base.pyi

@bk1e @zenforyen @askonomm @cazabon @kevin @ado

The type of w would have to encode all declarations of all some_method_of_my_object methods of my_object. You could define a interface (base class) for the type of my_object, so that the return value of create_wrapper_for_handing_over_to_thread_pool implements that interface, too.

In general, you don't use duck typing anymore, but are forced to verbosely declare and maintain interfaces and use generics all the time, like in #java or #cpp.