I don’t know about aliases specifically, but there are definitely people out there who like to define and use classes in function scope. It is commonly used in test suites, which often define similar structures, where it would be tedious to have to define everything at the global level and pick unique names for things in slightly different test scenarios. I would imagine this could include aliases.

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?


On Fri, Nov 5, 2021 at 14:51 Eric Traut <eric@traut.com> wrote:
Shannon, I'm fine with disallowing type aliases defined within a function scope. I struggle to come up with a compelling use case for this.

It sounds like we have consensus that type alias definitions (both implicit and explicit) should be allowed within class scopes. Unless someone disagrees, I think we can move forward with that plan.

Shantanu, thanks for volunteering to drive the next steps.

I've filed these three issues for myself in the pyright issue tracker:

https://github.com/microsoft/pyright/issues/2541 (Generate error when a type alias within an inner scope references a TypeVar bound to the scope)
https://github.com/microsoft/pyright/issues/2542 (Disallow type aliases within function scope)
https://github.com/microsoft/pyright/issues/2543 (Allow explicit type aliases within class scope)

Eric Traut
Contributor to Pyright & Pylance
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
Member address: guido@python.org
--Guido (mobile)