It's somehow September already, and time for our next tensor typing meeting!
WHEN? Monday 14th September, 9:30am San Francisco time, 5:30pm London time.
WHERE? Cyberspace, Google Meet. I'll post the link closer to the time.
1. Status updates
2. Alfonso: Arithmetic on tensor dimensions (Alfonso, do you wanna say
anything more on this?)
3. Matthew (short): Benchmarking stubs with thousands of overloads
I *might* also have something to present on the use of Ellipsis in the
annotations setup that Jörg and I and are working, depending on how this
week goes/how much time we have in the meeting.
I'm Dimitris and I work at Google on the XLA TPU compiler. Alfonso and I recently exchanged a few emails about a type that behaves like Any but just for ints, and he invited me to join this list. I've been interested in optional type systems for a while (I worked on Closure Compiler before joining my current team), so I'm happy to learn more about Python type systems.
Over the past few days, I tried out mypy using the playground, and wrote up a few thoughts here:
I found a few aspects of the semantics that were surprising to me but are intended behavior, and maybe a couple of cases where there are actual bugs (e.g., when joining union types, some elements of the unions may be dropped). Feel free to take a look at the post and let me know if you have any comments.
Pyright uses the following principles consistently:
1. Variable type annotations can be specified anywhere within the scope, and the location of the type annotation does not affect other aspects of type checking.
x = 42
x: int # This is fine
y = 42 # This should produce an error
2. A variable can be annotated more than once, but the annotations need to be consistent.
x: int # This is fine
y: str # This should produce an error
3. Type narrowing is always applied within the current execution scope using code flow analysis. (The location of the variable’s type annotation does not change this.)
4. The Any type is never narrowed. “Any” indicates that the type checker should not apply any type consistency rules to that symbol, so narrowing doesn’t make sense in this case.
These principles are consistent with static type checkers in other languages that I’m familiar with, and I think they are consistent with most users’ expectations.