Skip to content

[Bug]: Erroneous deprecation warning help message #22577

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

Closed
laolux opened this issue Mar 1, 2022 · 5 comments
Closed

[Bug]: Erroneous deprecation warning help message #22577

laolux opened this issue Mar 1, 2022 · 5 comments
Milestone

Comments

@laolux
Copy link

laolux commented Mar 1, 2022

Bug summary

When using the matplotlib.dates.epoch2num function I get a deprecation warning to use mdates.date2num instead. I cannot find out where mdates is supposed to be, but matplotlib.dates.date2num works pretty well.

Code for reproduction

import matplotlib
import matplotlib.dates
print(matplotlib.dates.epoch2num(123456789))
import datetime
print(matplotlib.dates.date2num(datetime.datetime.utcfromtimestamp(123456789)))

Actual outcome

Get a deprecation warning
The epoch2num function was deprecated in Matplotlib 3.5 and will be removed two minor releases later. Use mdates.date2num(datetime.utcfromtimestamp(e)) instead. print(matplotlib.dates.epoch2num(123456789))

Expected outcome

Get a more helpful deprecation warning with a function I can actually find and use instead of the deprecated one. For example
The epoch2num function was deprecated in Matplotlib 3.5 and will be removed two minor releases later. Use matplotlib.dates.date2num(datetime.datetime.utcfromtimestamp(123456789)) instead. print(matplotlib.dates.epoch2num(123456789))

Additional information

Maybe mdates is a common slang for matplotlib.dates for the developers of matplotlib, but this is not clear for the users. I have been trying quite a bit to see where I could get the mdates thing from. This should be easy to fix and make the deprecation warning even more helpful.

Operating system

Fedora

Matplotlib Version

3.5.1

Matplotlib Backend

No response

Python version

Python 3.10.2

Jupyter version

No response

Installation

Linux package manager

@oscargus
Copy link
Member

oscargus commented Mar 1, 2022

Maybe mdates is a common slang for matplotlib.dates for the developers of matplotlib, but this is not clear for the users.

That is a correct guess! The typical thing in the matplotlib code base is to write

import matplotlib.dates as mdates

You are also correct that it should not be used in the deprecation messages.

@oscargus oscargus added this to the v3.5.2 milestone Mar 1, 2022
@oscargus oscargus added Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues Good first issue Open a pull request against these issues if there are no active ones! and removed Difficulty: Easy https://matplotlib.org/devdocs/devel/contribute.html#good-first-issues Good first issue Open a pull request against these issues if there are no active ones! labels Mar 1, 2022
@oscargus
Copy link
Member

oscargus commented Mar 1, 2022

This is fixed in main, but maybe it should be back-ported to 3.5.2? At least for dates (but no harm for the other methods as well, right?)

#22038

@laolux
Copy link
Author

laolux commented Mar 1, 2022

During more testing I noticed a different issue. epoch2num behaves different than the proposed now method. epoch2num accepts numpy.ndarray as input, the new method only accepts scalar values. I think that is a more serious issue. Shall I open a now bug report for this?

@oscargus
Copy link
Member

oscargus commented Mar 1, 2022

Shall I open a now bug report for this?

Please do! (I'm trying to backport #22038 so that it ends up in 3.5.2 now and then I hope this issue can be closed.)

(Looking at the history, epoch2num has been deprecated and then un-deprecated before...)

@tacaswell
Copy link
Member

This was closed by #22578

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants