[DEVOPS] Deprecation warning wrapper for dict-like object renamed keys #2530
Conversation
There was a problem hiding this comment.
I've wanted something like this for a while, but IMHO it seems like it'll be quite difficult to comprehensively evaluate the consequences of modifying a DataFrame's __getitem__. @wholmgren said something similar here: #1403 (comment)
Additionally: although fixing df['old_key'] is probably the most useful part, there are other use cases that this doesn't address. Probably some of them are impossible to fix. Brainstorming:
- Exporting to other formats, e.g.
df.to_csv()orjson.dumps(d) - Iterating across keys, e.g.
for key in df:, could have issues - Splatting into functions that expect the old keys, e.g.
my_func(**d) - Computed values, e.g.
df.sum()['old_key']
Anyway, I tentatively think this PR is a good idea, but we need to carefully think about all the ways that pvlib is used and try to identify potential issues that aren't clear at first glance.
| On the other hand, ``pandas.DataFrame`` and other types may also expose | ||
| indexes as attributes on the object instance. In a ``DataFrame`` you can | ||
| either use ``df.a`` or ``df["a"]``. An old key ``b`` that maps to ``a`` | ||
| through the decorator, can either be accessed with ``df.b`` or ``df["b"]``. |
There was a problem hiding this comment.
Is this true? As far as I can tell, trying to access the old key using . raises AttributeError (as shown in the example a few lines down this docstring).
return_components=Truetransposition model outputs #2529 (see for other relevant comments, in pvlib threads)docs/sphinx/source/referencefor API changes.docs/sphinx/source/whatsnewfor all changes. Includes link to the GitHub Issue with:issue:`num`or this Pull Request with:pull:`num`. Includes contributor name and/or GitHub username (link with:ghuser:`user`).remote-data) and Milestone are assigned to the Pull Request and linked Issue.Threatening my mail inbox again, duh? Just kidding.
But let's give us the opportunity to make the renaming of all and any keys in returned dictionaries and dataframes be not a super, duper, user-angering, developer-exhausting, breaking change.
Key changes that come with this PR:
pvlib._deprecationfunctions listing. I've named it devops for now.I understand if there are objections to the new doc page. Suggestions, like whole removal, etc welcome. Just wanted to propose making the docstrings the first place to check, rather than finding past or current uses to see how to use the utilities in that deprecation submodule. I was unsure of the best fit for that, so in the contributing section it went..
Regarding, the new func / wrapper, I doubt there are no doubts. Let me know any objections, concerns, or ways to improve either the implementation or the tests, not covered by the documentation.
As always, a friendly proposal. If you want, I can also add an example of how this would look like for #2529 (quick search didn't give any useful results of other issues that may benefit from this).
Handy links for every1