Thanks Nipunn!

I concur... Everywhere that typed Python differs from untyped Python incurs a cost for the user, so I feel we should be approaching this from the default of allowing it. I'm not sure I see how supporting type aliases defined in functions is more complex than supporting classes that are locally defined in function scope — or does Pyre not support locally defined classes?

The line between classes and functions is blurry. For example, disallowing type aliases in functions would break code like:

```
def foo(x):
bar = map
return bar(lambda y: y+1, x)
```

because map is actually a class (and is typed as such in typeshed).

```

def foo(x):

bar = map

return bar(x)

```

On Tue, 16 Nov 2021 at 18:15, Nipunn Koorapati <nipunn1313@gmail.com> wrote:

I took a stab at a PR updating PEP 613, which gave me some thoughts.

> My only remaining question is – why support type aliases inside function scopes? I don’t think there is meaningful value-add, and having to deal with a different type hierarchy based on scoping sounds like unnecessary complexity to me. Similarly with type aliases defined as instance variables, or anything beyond toplevel globals or class variables, which are essentially qualified globals.

> Is there a technical reason to exclude them? Python in general has a
philosophy that allows you to combine structures arbitrarily. We allow
imports in functions. Why not type aliases?

In terms of spec complexity, I believe having different behavior for TypeAlias within functions vs classes vs global scope adds complexity to the spec (eg see scope-restrictions section of https://github.com/python/peps/pull/2154).

It may be worth adding such spec-complexity in order to mitigate technical complexity - but I think such cases are rare. Usually spec simplicity is worth working for. If we allowed type aliases in functions, I think we could leave out the entire scope-restrictions section. I'm not familiar with the technical challenges of implementing type hierarchies - so I'll certainly defer to others here who work on type checkers.

Per guido's point, this would be in line with python's general philosophy, but I'm also sympathetic to the point that type checking in python might want to be stricter than python's general philosophy. Is there some way to get the appropriate strictness while maintaining spec simplicity?
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: hauntsaninja@gmail.com