Cosmo: type annotate the optimization functions#15853
Conversation
|
Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.
|
|
👋 Thank you for your draft pull request! Do you know that you can use |
|
Need |
8e1a839 to
c7b3fd6
Compare
c7b3fd6 to
de274d3
Compare
|
Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then. In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary. If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. If you believe I commented on this pull request incorrectly, please report this here. |
de274d3 to
7969a18
Compare
e6e537b to
544c68c
Compare
|
I'm hesitant to add the types |
|
In a greenfield project I would insist on documenting all types that are used in the public API, but |
544c68c to
b9cfdc7
Compare
|
Test failures unrelated. |
|
|
||
|
|
||
| # TODO: it would be nice to upstream this to scipy and then use it here. | ||
| class _CustomMethod(Protocol): |
There was a problem hiding this comment.
Why is this implemented as a Protocol with a __call__() method instead of something like
_CustomMethod: TypeAlias = Callable[..., OptimizeResult]And is _CustomMethod the best name for this?
There was a problem hiding this comment.
Because the structure of _CustomMethod is more specific than that. It has to have a signature like
(fun: Callable[..., Any], args: tuple[Any, ...], **kwargs: Any) -> OptimizeResult.
But I agree about a better name!
Signed-off-by: nstarman <[email protected]>
Signed-off-by: nstarman <[email protected]>
b9cfdc7 to
011c6c9
Compare
| from typing import Any, Literal | ||
| from typing import Literal | ||
|
|
||
| from typing_extensions import Unpack |
There was a problem hiding this comment.
Unpack is used in a few places to unpack **atzkw. That functionality was added to Unpack in Python 3.12 (see PEP 692 – Using TypedDict for more precise **kwargs typing). I'm willing to guess that the reason for importing Unpack from typing_extensions instead of typing is to make that functionality available in Python 3.11. But apparently typing_extensions.Unpack only backports the changes to Unpack.__repr__(), not the ability to unpack **kwargs, which means that the new type annotations are valid for Python 3.12 and later, but not for Python 3.11.
There was a problem hiding this comment.
Unpack has been in typing since 3.11.
There was a problem hiding this comment.
In Python 3.11 typing.Unpack can only be used to unpack tuples.
There was a problem hiding this comment.
Then does it come through as an Any? My mypy isn't flagging any issues.
There was a problem hiding this comment.
I haven't tested this with Python 3.11.
There was a problem hiding this comment.
So what's the step forward? Merge as-is and wait for mypy checking of cosmology?
There was a problem hiding this comment.
It is possible that I am misunderstanding the typing_extensions documentation and this is actually not a problem. Someone should type check this with Python 3.11 to find out for sure.
There was a problem hiding this comment.
I looked into it more. It doesn't do it. Sigh. I kind of don't want to change it, but should. Just defeats the point of adding _ZAtValueKWArgs
There was a problem hiding this comment.
Working around it the gross way.
There was a problem hiding this comment.
That's not the prettiest code, but it has no effect at runtime, we only need it until we drop support for Python 3.11 and Ruff will not let us forget about it when we do.
Signed-off-by: nstarman <[email protected]>
Followup to #15852
Plz squash.