Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removed ABCs from pandas._typing #27424
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
Removed ABCs from pandas._typing #27424
Changes from 11 commits
9c6e616
6490263
cce9afb
1fe6059
5f2fa6a
72d3e2c
c3bd6df
5a8d35a
5889715
ed2ee7f
095aed4
4bf254c
8f4a7a1
5e77b75
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
quote from https://mypy.readthedocs.io/en/latest/generics.html...
"User-defined generics are a moderately advanced feature and you can get far without ever using them..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks but this just loosens the type system rather than actually fixing anything. TypeVar is going to be generally more useful for checking functions that can be fully generic in nature.
Might just change the return of this one and see how many others require Union in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense. Union[Series, DataFrame] might be better written as NDFrame anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also the "user-defined generics" you are referring to are more applicable to containers not TypeVars. Right now we just use a blanket
Series
as a return object, though in the future we could do something likeSeries[int]
andSeries[str]
, etc...; theSeries
would be the user-defined generic in that caseThe TypeVar in the docs you linked is just a way of parametrizing that user-defined generic, so that a
Series[int]
would have to stay as aSeries[int]
through it's lifecycle; without that parametrization we allowSeries[int]
to becomeSeries[str]
without any complaints from mypy todayWe are probably a ways off of doing user-defined generics but this is great that you looked into it. Certainly open to ideas on that front if you think of a good way to implement as we get more familiar with these annotations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm that would work though we don't typically import NDFrame anywhere so I don't think want to start here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would leave as FrameOrSeries as its more descriptive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you also make
AnyArrayLike
an Alias instead of a TypeVar, then this module doesn't need to be changed at all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing though - this just loosens the type checking which isn't desired. Actually moved towards TypeVars for reasons described in #26453 (comment)
Might update #27050 to include some of that info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think that applies here.
target
does not need to be a TypeVar, the type oftarget
does not need to be maintained.target
can be any of["ExtensionArray", "Index", "Series", "SparseSeries", np.ndarray]
ensure_index
is not yet typed. but presumably will have a return type ofIndex
.so reassigning with an
Index
to a variable that has a type of Union of["ExtensionArray", "Index", "Series", "SparseSeries", np.ndarray]
is perfectly valid.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add Union alternatives for each TypeVar in the central module but I think that confounds the point of generic programming and/or makes our type system weaker. Another option would be to allow redefinition of variables which mypy supplies a setting for:
https://mypy.readthedocs.io/en/latest/command_line.html?highlight=allow-redefinition#miscellaneous-strictness-flags
But I also think that makes for a weaker type system, and generally there's not a lot of downside to creating a separate variable here instead of allowing it's type to implicitly be altered by the return of
ensure_index
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely. we should rule this out.
disagree. the return type of
ensure_index
would need to conform to the type oftarget
.is creating new variables not weakening the type system?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not ideal to remove
FrameOrSeries
here but mypy was complaining since this function is not fully generic (i.e. a conditional branch could determine the returned object)Options discussed were:
I looked at option 1 first it caused a lot of flake8 complaints with other imports in the module where we import Series directly within a function, so would add a lot of noqa directives to the file to make it work. Option 2 was suggested by @simonjayhawkins and would be viable but I figured just remove for now and can open up a follow up issue to try and make this function generic.
It was type checking to
Any
before this change anyway so we aren't loosing any inference. Open to thoughtsThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
adding
Any
(or not typing) is not so bad. There is a network effect benefit from typing, so the quicker we add type hints to modules, the quicker we see a benefit.having
Any
can easily be picked up in a future pass with one of many cli flags to mypy.so I don't think any PRs adding type annotations should be held pending perfection (and especially unrelated PRs with "Any interest in adding an annotation while you are looking at this?" . xref #26795)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so we are on the same page anything without an annotation is implicitly
Any
so typing it as such doesn't change anything.How do you view the
Any
annotations currently in the code? I interpret that as "this has already been reviewed and really should allow anything" versus "I just addedAny
to get this to pass". I don't see a lot of value add to the latter since that's what happens implicitly without an annotation anyway but certainly a point for discussionThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for this. I strongly prefer to leave something un-typed as an invitation to the next person to try to figure it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just done an experiment.. it appears that Any is considered a type annotation and so the code gets checked, whereas leaving it out causes the type checker to not check the code.
so -1 for not adding Any to un-typed function signatures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's a case where having a function typed with Any everywhere is valuable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not everywhere!
just where they are currently omitted because the union is of too many types. such as key in indexing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have to double check but it's not the field you were actually annotated that throws the error as much as something else right? I think mypy might skip a function if it has no annotations so adding Any may cause it to throw errors for inferences of local variables it can't make.
With that said I really don't think adding
Any
is a great approach. If we wanted the former there is a--check-untyped-def
flag we could enable.This thread is probably best as a separate issue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's correct. or even incorrect calls to typed functions.
disagree.
ok locally for a module, but how to set-up on the CI? if we are typing gradually we are not yet ready for this.
Adding Any to a function, indicates the body of that function is ready to be type checked.
i'm opening another PR shortly, where Any is added for all unions of 5 or more items. https://monkeytype.readthedocs.io/en/latest/generation.html#monkeytype.typing.RewriteLargeUnion so we can continue the discusion there.