-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
CLN/INT: avoid getattr(obj, 'values', obj) idiom #27167
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
Comments
yep this is a good idea |
This is my preference. We have |
ahh yes if we rename to ensure_array and put in dtypes.common would be consistent |
Generally on board, question about exactly what you have in mind:
Do you have a strong opinion on this versus |
We use this idiom quite a bit in the code base:
One example:
pandas/pandas/core/algorithms.py
Line 123 in ad2e98c
Personally, I find that this makes the code harder to reason about. What kind of object is
values
? What does the.values
attribute return? (which depends on the object and dtype).I think a more explicit coding can make things clearer. Sometimes I would find it clearer to just do:
This is longer, yes, but then it is at least clear that it can potentially be a Series.
Although we should probably even try to avoid that algorithmic code is dealing with a mixture of Series, Index, EA, ndarray. I think, in general, we should nowadays be able to unpack containers in the beginning of / before algorithmic code so we know we only have either ndarray or EA.
Eg we could have an
ensure_array
that does such explicit checks and ensures the values are ndarray or EA.cc @jreback @jbrockmendel @TomAugspurger
The text was updated successfully, but these errors were encountered: