CLN: circular/runtime imports in tslibs #34563
Conversation
…f-delta_to_nanoseconds
…f-delta_to_nanoseconds
…f-delta_to_nanoseconds
…f-delta_to_nanoseconds
| @@ -123,6 +122,7 @@ timedelta-like} | |||
| elif nonexistent == 'shift_backward': | |||
| shift_backward = True | |||
| elif PyDelta_Check(nonexistent): | |||
| from .timedeltas import delta_to_nanoseconds | |||
There was a problem hiding this comment.
does it make sense to move delta_to_nanoseconds even higher eg to base.pyx ?
There was a problem hiding this comment.
ive considered this and gotten hung up on attribute lookup behavior which isnt doing optimizations that i think it should. I'd like to punt on this for now until I get that sorted out.
| @@ -49,7 +47,9 @@ from pandas._libs.tslibs.timezones cimport utc_pytz as UTC | |||
| from pandas._libs.tslibs.tzconversion cimport tz_convert_single | |||
|
|
|||
| from .timedeltas cimport delta_to_nanoseconds | |||
|
|
|||
| from .timedeltas import Timedelta | |||
There was a problem hiding this comment.
are we consisten about relative imports? I really don't like mixing this.
There was a problem hiding this comment.
we're not, but the above line is relative so i figured this should be too since its the same module.
while we generally do absolute, i think we should move to relative for tslibs since self-containment is a big deal here
|
ok fair, but we should document this somewhere i think. |
ATM tzconversion depends on timedeltas (for delta_to_nanoseconds), which throws a wrench in the erstwhile dependency hierarchy. By making the one usage of delta_to_nanoseconds a runtime import, we make it possible to remove a bunch of other runtime imports.