You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Per my comments in pandas-dev/pandas#18141, I think that it is not particularly expensive to preserve some of the private interface, with an explicit deprecation warning.
The main question I have here is whether we should use DeprecationWarning, which is not visible by default in Python 2.7+, or if we should use something more visible, like our own custom warning class that is visible, or possibly make some sort of context manager that temporarily enables DeprecationWarning.
Kinda unfortunate that DeprecationWarning was disabled by default, since that encourages libraries to do shit like what I just described, but it is what it is.
@jbrockmendelFutureWarning is intended for when the semantics of something change. I think you'd use it in a case like Python 2 integer division behavior vs. Python 3 integer division behavior. Or presumably if we thought it mattered, we could raise a FutureWarning when two time zones of the same type compare equal but tz1 is not tz2, to say that semantically equal time zones of the same type will have a different semantic relationship to one another in the future. This PR deprecates an old (private) interface, so DeprecationWarning is more appropriate.
In any case, avoiding DeprecationWarning just so it's visible isn't much different from just defining a DeprecatedPrivateInterfaceWarning and raising that. The question is really whether we want to circumvent the default behavior of hiding deprecation warnings or not.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Per my comments in pandas-dev/pandas#18141, I think that it is not particularly expensive to preserve some of the private interface, with an explicit deprecation warning.
The main question I have here is whether we should use
DeprecationWarning, which is not visible by default in Python 2.7+, or if we should use something more visible, like our own custom warning class that is visible, or possibly make some sort of context manager that temporarily enablesDeprecationWarning.Kinda unfortunate that
DeprecationWarningwas disabled by default, since that encourages libraries to do shit like what I just described, but it is what it is.