PEP 718: subscriptable functions

Many of the arguments for why we need this listed in the PEP can be read instead as “my type analyzer can’t do its inference job, so lets change the language to allow humans to do the job instead”. That doesn’t come across as compelling. Why not improve the type analyzer?


This syntax also provides us with something akin to the Markdown syntax linkification delimma of ordering the parens and brackets properly:

People will now be able to put [] and () in the wrong place and instead of an obvious error that could produce an error message telling them what specifically was wrong for having typed frob.fetch[stuff](key) when they meant a non-typing-related frob.fetch(stuff)[key]… it’ll have what behavior exactly?

It looks like it’d devolve into a fetch(key) call rather than fetch(stuff) and produce whatever error, if any, that might cause somewhat removed from the source of what was actually a syntax problem?


It wasn’t obvious to me from the PEP text when this syntax was intended to be used? At source analysis time by type analyzers much like an annotation? Or at runtime? It clearly has a runtime performance impact to use it. There’s an extra expression in the [], getitem call, GenericAlias object construction, return, and indirect call through the GenericAlias.__call__ implementation happning.

9 Likes