The 'generic' unit for NumPy timedelta is deprecated. #2914

Activity

1. DMZ22 commented on Jul 22, 2026

   

   DMZ22

   on Jul 22, 2026

   Contributor

   More actions

   Looked into this. The utils.py site was already reworked on dev in d8e2cfe (sub-day intervals now map to explicit units), and #2915 fixes the remaining quote.py site plus a TypeError regression d8e2cfe introduced for the "5d" interval.

   One thing I could not do is reproduce the generic-unit warning itself — tried pandas 2.3.3/3.0.3 x numpy 2.4.6/2.5.1 on Python 3.11/3.12/3.14, all clean. Could you share your numpy version (python -c "import numpy; print(numpy.__version__)")? Wondering if it needs a numpy dev build to trigger.
2. andriy-git commented on Jul 22, 2026

   

   andriy-git

   on Jul 22, 2026

   Author

   More actions

   I know I didn't install any dev packages on this venv. Here are the versions I am using:
   NumPy is version 2.5.1
   Pandas is version 2.3.3

   After bumping Pandas to version 3.0.3, I stopped getting the deprecation warning. So there is some incompatibility between Pandas and NumPy.
3. DMZ22 commented on Jul 24, 2026

   

   DMZ22

   on Jul 24, 2026

   Contributor

   More actions

   Thanks for the versions — that was the missing piece, and it let me reproduce it. My earlier "can't reproduce" was wrong: the trigger is numpy ≥ 2.5.0, and I had been testing against 2.4.6.

   Built your exact stack (Python 3.14, numpy 2.5.1, pandas 2.3.3) and pinned it down. The warning has nothing to do with yfinance — it comes from inside pandas, on any Timedelta construction:

   >>> import pandas as pd
   >>> pd.Timedelta('1d')
   DeprecationWarning: The 'generic' unit for NumPy timedelta is deprecated ...
     File "pandas/_libs/tslibs/timedeltas.pyx", line 1845, in
           pandas._libs.tslibs.timedeltas.Timedelta.__new__

   No yfinance imported. pd.Timedelta(days=1) does it too. The comparison and the subtraction in those two tracebacks are both clean — it is purely the Timedelta(...) call, so quote.py:254 and utils.py:667 are just the first two constructions a normal session happens to reach.

   Version matrix, all on Python 3.14:

   numpy	pandas	result
   2.4.6	2.3.3	clean
   2.5.0	2.3.3	warns
   2.5.1	2.3.3	warns
   2.5.1	3.0.0	clean
   2.5.1	3.0.3	clean

   So it is a pandas-2.x/numpy-2.5 incompatibility, exactly as your pandas bump suggested. Worth noting 2.3.3 is the final 2.x release, so that line will not be getting a fix — upgrading to pandas ≥ 3.0 is the only remedy.

   One thing for the maintainers: setup.py currently asks for pandas>=1.3.0 and numpy>=1.16.5, so pandas 2.3.3 + numpy 2.5.1 is a fully legal resolution of yfinance's own constraints and this will keep being reported. Might be worth either documenting it or requiring pandas>=3.0 when numpy>=2.5.

   Also flagging so this doesn't get closed by the wrong thing: #2915 is unrelated to this warning. It fixes a genuine TypeError regression on the "5d" interval plus some date-arithmetic patterns, and it will not silence this deprecation — nothing in yfinance can, since the warning is raised before yfinance's own code gets involved.

   🎉React with 🎉1Reacted by andriy-git
4. DMZ22 commented on Jul 25, 2026

   

   DMZ22

   on Jul 25, 2026

   Contributor

   More actions

   Small correction to what I said earlier. I claimed nothing in yfinance could silence this and only a pandas upgrade would — that's only half right.

   The warning does come from inside pandas' Timedelta construction, so a Timedelta you build yourself will still warn until pandas 3.0. But yfinance controls how it constructs the Timedeltas on the two lines from your traceback, and it turns out the construction form matters on this stack (numpy 2.5.1 / pandas 2.3.3):

   • pd.Timedelta(days=548) and pd.Timedelta(minutes=90) — the keyword forms — still warn
   • pd.Timedelta(548, unit="D") — the (value, unit=...) form — is silent

   The existing workaround for #2882 used the keyword form, so it never actually suppressed the warning — its regression test fails on numpy 2.5.1. #2915 switches those sites (including quote.py:254, the first line in your report) to the unit= form and also fixes a TypeError for multi-day intervals like "5d". So the specific lines you saw the warning on are addressed there. Thanks for pushing back on the version details — that's what surfaced it.

   👍React with 👍2Reacted by andriy-git and Parthozyy
5. parthozyy commented on Jul 25, 2026

   

   parthozyy

   on Jul 25, 2026

   More actions

   I opened PR #2921 to address the remaining FastInfo.shares warning reported here:

   #2921

   The PR replaces pandas Timedelta arithmetic on a Python date with the standard-library datetime.timedelta, updates the equivalent test code, and adds a deterministic regression test.

   The targeted tests pass:

   Ran 2 tests in 14.484s
   
   OK
   
6. andriy-git commented on Jul 25, 2026

   

   andriy-git

   on Jul 25, 2026

   Author

   More actions

   This doesn't add anything, but you guys are on fire. The maintenance of this library is a well-oiled machine.

   ❤️React with ❤️3Reacted by Parthozyy, Devashish Moghe and Alessandro Colace
7. parthozyy commented on Jul 25, 2026

   

   parthozyy

   on Jul 25, 2026

   Last edited by parthozyy

   More actions

   @DMZ22

   Thanks for the detailed investigation. I now understand that, with pandas 2.3.3 and NumPy 2.5.1, the keyword form itself can trigger the warning:

   pd.Timedelta(days=548)

   while the explicit-unit form does not:

   pd.Timedelta(548, unit="D")

   Your explicit (value, unit=...) approach makes sense for the interval-handling code in utils.py, where yfinance needs to construct pandas timedeltas from interval values.

   For the FastInfo.shares line specifically, however:

   pd.Timestamp.now("UTC").date()

   already returns a Python datetime.date. Using:

   datetime.timedelta(days=548)

   keeps the calculation entirely within Python’s standard datetime types and avoids constructing a pandas/NumPy timedelta altogether.

   I opened #2921 specifically to address the FastInfo.shares warning with this approach. Would you be open to removing the overlapping quote.py change from #2915 and keeping #2915 focused on:

   • _interval_to_timedelta
   • the warning in utils.py
   • the multi-day interval TypeError

   That would give the two PRs separate scopes:

   • Fix generic timedelta warning in FastInfo #2921 — FastInfo.shares
   • Fix multi-day interval TypeError and actually silence the numpy>=2.5 Timedelta warning #2915 — interval conversion and multi-day interval handling

   I want our PRs to have different contributions so i am requesting you to remove the overlapping change
8. Pavankalyan32 commented on Aug 13, 2026

   

   Pavankalyan32

   on Aug 13, 2026 · Hidden as spam

   show commentMore actions
9. JaneSmith540

   added 2 commits that reference this issue on Aug 19, 2026

   Fix numpy>=2.5 generic-unit DeprecationWarning for interval parsing (r…

   ...

   5420d87

   Fix numpy>=2.5 generic-unit DeprecationWarning for interval parsing (r…

   ...

   6c996a7
10. ValueRaider

    closed this as completedon Aug 24, 2026