Am 29.06.22 um 00:53 schrieb Eric Traut:
> * Sebastian suggested that there might be better alternatives to the colon token for specifying an upper bound or constraints. Potential replacements include "<" or "<:". (Note: I think I still prefer colon here, but that might be because of familiarity.)
While most other punctuation is familiar from other parts of Python,
colons are only used as block start and for type annotations so far. My
suggestion was to use "T(int)" to signal a sub-type relationship,
similar to how sub-class relationships are declared, but that might not
be obvious either. As Python is usually a fairly verbose, keyword-based
language, maybe it could also make sense to use a keyword for this.
Actually I like T(int) a lot, and it avoids giving new meanings to ':' or inventing new tokens. And if we declare the syntax as being a function call parameter list, we can get creative with future extensions like default=X. Only problem is that it would look like T(str, bytes) might supply a "type constraint" (like AnyStr) but we want T(int) to behave like TypeVar("T", bound=int). This is solvable though without adding new syntax.
Regarding extensibility: Apart from defaults (which we will need in a
foreseeable future), what features do other languages have for type
variables that we don't yet? Is it even likely that we will extend type
variables in the future?
I dunno.
Regarding your other message, I agree that the runtime solution still feels hacky. I'm not sure what new fundamental idea we could introduce though -- maybe a new "configurable" scope that is visible for reads but invisible for writes? IIRC Eric rejected this after finding out how tricky it would be to implement (new bytecodes etc.), but maybe that's still the right solution.