Evolve current type hints to typescript syntax

Compared with the current type hint, typescript is more complete, convenient, flexible and concise.
Eg. function type define
ts

type IDHandler = (id: number) => number;
const handler: IDHandler = (id) => {
  return id
};

Function of the argument is prompted by name.
Can define function base on type
py

from typing import Callable

IDHandler = Callable[[int], int]
No way

Eg. dict type define
ts

type XID = "A" | "B" | "C";
type XName = string;
type XDict = { [key in XID]: XName };
type PartOfXDict = Partial<XDict>

py
Difficult to achieve the same effect
Eg. generic…
Eg. interface in ts…
etc
All type hints in python seem to be evaluated until they can no longer be evaluated, losing the meaning that variable names add to types during assignment.
However, typescript clearly displays the whole process of type assignment.
Type hints of PY are inspired by TS, but are not as complete as TS. Why not just translate directly?
Type hints play an important role in standardization, maintainability, and scalability of programs. TS can do whatever I want to do, just like an optional static language, but type hints of python can’t.
Is there anyone who thinks the same way I do, at least pushing it in this direction?
I make an issue in ts

Various of these individuals suggestions have been made over the years and either withdrawn or rejected.

If you genuinely want to see some of these, pick one and do quite a bit of research and see what previous counter arguments have been made and see if you can construct a specific proposal that avoids all those issues and stands on its own without needing to refer to TS for motivation.

The biggest issue is going to be that type hinte are expressions and therefore any syntax you come up with will be valid anywhere.

1 Like

There are several TypeScript type expressions I’d like to see in Python (such as utility and mapped types), but I don’t think the comparison is symmetrical.

TS is an entire language built on top of JS. It has syntax and constructs that don’t exist in the latter, some of which even differ/conflict with ECMAScript proposals (e.g. decorators). And it all becomes plain JS, whether you use bundlers or Node.js’ experimental support for TS.

CPython type hints, on the other hand, are implemented within CPython itself. This has the advantage of not requiring any transpilation machinery, at the cost of having a little less flexibility, since these type hints are implemented on top of existing language constructs.

In the current scenario, it’s more reasonable to tackle/propose features one at a time than to adopt a language superset.

4 Likes