> 1. You can define a function type somewhat clumsily (`Callable[[Arg1T, Arg2T], ReturnT]`), but if your callback uses keyword arguments (pervasive among Python programs), you're out of luck.

I've personally never missed the ability to add keyword arguments to a Callable. If you want to anyway, I understand that at least mypy has syntax for this:

* https://mypy.readthedocs.io/en/stable/protocols.html#callbac...

* https://mypy.readthedocs.io/en/stable/additional_features.ht...

> Beyond that, it's just the general usability issues that ultimately derive from Python's election to shoehorn a lot of typing functionality into minimal syntax changes

Many syntax niceities will be introduced in upcoming Python releases. From the article:

* Union types are shortened to X | Y (PEP 604)

* (?) Optional types shortened to X? (PEP 645)

* Type Hinting Generics In Standard Collections (PEP 585) - Can use list[T], dict[K, V], etc in place of List[T] and Dict[K, V].

With those changes, you won't generally need to import the `typing` module at all anymore.

> there just isn't enough investment to move it forward.

Dropbox has dedicated engineers maintaining mypy. And of course a few volunteers such as myself. And Guido. :)

More annoying for our codebase is the inability to specify optional/default arguments with closures. We often use functions that return other functions and you can't persist the "optional state" without using a protocol. It would be great just to match the current state of vanilla defs with optional params.

For example:

  def make_fun1(a: int) -> Callable[[int, Optional[int]], str]:
      def fun(b: int, c: Optional[int] = None) -> str:
          if c:
              b += c
          return f"{a+b}"

      return fun

  fun = make_fun(1)
  fun(2)

Will give you `Too few arguments` for `fun(2)`

You can fix this with something like:

  class FunC(Protocol):
      def __call__(self, b: int, c: Optional[int] = None) -> str: ...

  def make_fun(a: int) -> FunC:  ...

But that that seems like unnecessary overhead, because the non-nested def case can happily understand the optional parameter.

> I've personally never missed the ability to add keyword arguments to a Callable. If you want to anyway, I understand that at least mypy has syntax for this

Neat, I didn't realize this. This is far from desirable, but nice to know it's possible.

> Many syntax niceities will be introduced in upcoming Python releases. From the article:

I mean, typing out "Union" and "Option" or even having to import generic types from the typing module aren't really the syntactic pain points I was referring to. It's more like "Where do I define the TypeVar for a generic method on a class? Do I define it inside of the class or at the top-level module? In either case, if I reference that variable in another method, does it imply that these two types are the same? No doubt there are answers, but Python is the only language in which I have to navigate these kinds of questions. Similarly, having to create a protocol for kwarg callbacks seems really heavy. These are the kinds of things I would like to see improved.

> Dropbox has dedicated engineers maintaining mypy. And of course a few volunteers such as myself. And Guido. :)

Yes, I didn't mean to suggest there was no investment, only that the progress seems really slow (also, I didn't realize Guido was a volunteer? I thought he was employed by DropBox to work on Python). How long have recursive types been in a holding pattern, for example? I don't mean to disrespect you or any of the other maintainers--no doubt you're doing great work.

I definitely prefer the TypeScript dev experience for larger/longer-term projects, all else being equal. You spend an hour or two configuring your build tooling and then don't really have to mess with it much after that. But I also never bother setting up TypeScript for JS one-offs or scripts (where I would bother to add Python type annotations in those cases), so make of that what you will.

Deno is currently trying to bridge that gap - putting TS directly in your interpreter - but right now it comes with some caveats around being a separate runtime with incompatible system APIs, unfortunately. We'll see if it takes off enough that that becomes less of an issue.

Aside:

> it's a problem made difficult by an accumulated legacy of unfortunate decisions and there just isn't enough investment to move it forward

This is funny to me because JS has an even bigger accumulated legacy of unfortunate decisions, it's just gotten an obscene amount of investment to move it forward despite all odds ;)

If your callback uses kwargs, you define a Protocol that describes __call__ with typed kwargs, and use that as the type. Yes, it’s clunky, but it’s possible to do.

Imagine ...

1. a -> b :: Function(a)[b]

   (a, k1=t1, k2=t2) -> b :: Function(a, k1=t1, k2=t2)[b]

2. JSON = RecTypeVar('JSON', lambda Self: Union[None, bool, int, float, str, List[Self], Dict[str, Self]])

huh!

> 2. JSON = RecTypeVar('JSON', lambda Self: Union[None, bool, int, float, str, List[Self], Dict[str, Self]])

You don't actually need this workaround—the problem is typechecker support, not syntax. You can use strings for forward definitions, like this:

  JSON = Union[str, int, None, bool, List["JSON"], Dict[str, "JSON"]]

What happens next depends on your typechecker. Mypy says this:

  error: Cannot resolve name "JSON" (possible cyclic definition)

Pytype says this:

  Recursive type annotations not supported yet

But Pyre accepts it and correctly uses it for typechecking.

In fairness I find (1) to even less readable than the existing Callable syntax, but yeah, it would be cool if Python could express callables with kwargs and recursive types.