random thought: whether `mypy` needs to check tran...
# development
w
random thought: whether
mypy
needs to check transitive dependees is dependent on whether a file “exports” a type… and the same goes for
javac
, where we actually implemented “exports” (described in the JVM inference post)
but there is some … circularity … involved in actually figuring out which types are exported. we can do it in Java because return types and non-local variables must have their types declared, and so dependency inference can indicate that certain symbols get exported.
doing the same with mypy would involve recursively invoking mypy … upward in the graph …? with a plugin that told you which other modules a file consumed…?
b
What would be the gain?
w
if you change an implementation detail (such as a method body) rather than a public API like a return type or method, then we would not need to
check
dependees
🤔 1
b
I think wiring the mypy cache gets us a lot fo the way for perf. This would be an orthogonal bonus perf
w
yea.
it’s primarily significant in huge repos
cc @ancient-vegetable-10556 since you worked on exports
b
Seems doable assuming we could ask mypy for the info
You'd need to run using the users mypy PEX IMO,so it'd need to be supported across a wide range of versions
w
yea, tricky. and actually, unlike dependency inference in general, getting this wrong could lead to under-checking/compilation.
(i.e.: if you fail to notice an export, you don’t check a dependee that you did need to check.)
1
h
Supporting the mypy cache and daemon might be bigger wins?
1
h
yeah mypy is already pretty fast w/o pants
b
@hundreds-father-404 that's what I said about `black`and it's cache 😹
But also yeah I think cache would be a heavy hitter. In the spirit of blazing fast CI though: porque no Los dos?
☝️ 1
h
Porque esto es complicado?
🇲🇽 2
b
I think the two ideas are orthogonal enough to not complicate each other