-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What to do with deprecated public submodules #48
Comments
Actually I saw how @jorenham has done it in files like # This file is not meant for public use and will be removed in SciPy v2.0.0.
from typing_extensions import Never, deprecated
__all__: list[Never] = []
@deprecated("will be removed in SciPy 2.0.0.")
def __dir__() -> list[Never]: ...
@deprecated("will be removed in SciPy 2.0.0.")
def __getattr__(name: str) -> Never: ... # pyright: ignore[reportIncompleteStub] Just need to copy it like this? This should be simple to auto-replace using a script I think. |
Yea there's quite a couple of those; good question I'm not sure anymore whether In other modules, e.g. Usually, these deprecated modules are simply re-exports of other (private) modules, so you could just place a comment saying that it's deprecated, and then just re-export them. I also wouldn't mind if you'd use a "dummy" function with a @deprecated("don't")
def loadmat(*args: object, **kwds: object) -> object: ... Either way, we should probably try to minimize the amount of |
it's too bad that |
Yes in regards to "I'm not sure anymore whether getattr and dir are the way to go actually.", it seems to obscure the type checker's ability to reason about the attributes' type. Does adding This would be a lot more work though because you would need to duplicate the type annotations rather than just the names like in the re-export approach. |
You're right; and that's precisely the reason why I decided to disallow them in
I know that at least VScode supports it in a very helpful manner. I don't think that mypy currently supports it, but pyright (==pylance) do.
Yea I agree that it's not very DRY. But unfortunately, code duplication is something very common in python typing (which I'm currently trying to tackle through But I consider The main priority is to have complete Either way, I guess I'm fine with whatever you decide on this point. |
Ok got it. I am actually not too familiar with the tools as of right now. What is the expected output of |
Assuming that you have $ poe stubtest scipy.special -- --ignore-unused-allowlist
Poe => stubtest --mypy-config-file=pyproject.toml --allowlist=tests/stubtest/allowlist.txt scipy.special --ignore-unused-allowlist
Success: no issues found in 100 modules similarly, you can run $ poe mypy special
Poe => mypy --config-file=pyproject.toml scipy-stubs/special
Success: no issues found in 19 source files
$ poe pyright special
Poe => basedpyright scipy-stubs/special
0 errors, 0 warnings, 0 notes and $ poe lint
Poe => ruff check
All checks passed! (so ruff is already happy with everything) The "unfinished" modules indeed produce errors in stubtest at the moment. So when you're tackling a package or module, you can consider it "complete" if there are no stubtest errors left. I'm planing to write a contributing guide soon, see #50 |
This apparently was auto-closed, sorry for that. |
I think my PR mostly closes this issue. There might be a few more deprecated modules though because I only did ones where the stub had an exact match to the template I made so I guess until they are done we can leave this issue open? |
Yea sounds like a plan |
There are various currently public submodules in scipy that are to be deprecated in scipy v2.0.0 such as
io.matlab.mio
. These files simply have two functions that are really overrides of the standard module functions__dir__
and__getattr__
in order to display deprecation warnings.For example this is
scipy/io/matlab/mio.py
.The most obvious type hints for this
def __dir__() -> list[str]: ...
anddef __getattr__(name: str) -> Any
. Is this good enough?Would there be any alternatives to using
Any
in the case of the second? I feel like this would obscure the type of attribute being accessed but I'm not sure giving concrete types are possible at all or desirable.If the type hints I suggested are okay I can go and make a PR to add these type annotations to every instance of this pattern.
The text was updated successfully, but these errors were encountered: