Fix performance regression on numerical libraries - #22030
ilevkivskyi wants to merge 4 commits into
Conversation
This comment has been minimized.
This comment has been minimized.
|
OK, the crash is good, it uncovers a flaw in callable unioning logic: We should not combine callables with unpacked |
This comment has been minimized.
This comment has been minimized.
|
This looks fine, but the original PR seems to have also regressed this (false negative): from typing import Protocol, overload
class P(Protocol):
def __call__(self, x: int | str) -> int | str: ...
@overload
def f(x: int) -> int: ...
@overload
def f(y: str) -> str: ...
p: P = f # accepted, but shouldn't be
p(x="s") # fails at runtime |
This was semi-intentional. This kind of subtyping usually appears in the context of method overrides (not in context of callback passing) were we currently use |
|
It looks like GitLab has some kind of outage and consequently |
|
Diff from mypy_primer, showing the effect of this PR on open source code: scikit-learn (https://github.com/scikit-learn/scikit-learn)
- sklearn/externals/array_api_extra/testing/_testing.py:389: error: Unused "type: ignore" comment [unused-ignore]
|
|
The primer is good, it was a false negative (different positional argument name were ignored). |
My recent PR #22007, that improved overload vs callable subtyping, introduced ~10% performance regression on pandas/numpy/etc. There is no point in simplifying unions in code that is not visible to the user. Also
m^2 / 2 + n^2 / 2 >= mnfor allmandn, so IIUC this should be strictly better now.cc @JukkaL