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
DeprecationWarning in json/encoder.py #74249
Comments
I have started receiving the following warnings which are starting to prevent an ipython session from functioning: /home/user/anaconda2/envs/cdatcmornclnco/lib/python2.7/json/encoder.py:207: DeprecationWarning: Interpreting naive datetime as local 2017-04-12 17:15:36.235571. Please add timezone info to timestamps. The only way I can continue is to terminate the ipython shell and open a new instance. Can someone tell me what I need to do to solve the issue? Is there a json import somewhere that requires some new arguments? |
I have attempted to quieten these using: In [2]: import warnings However, this doesn't seem to be working |
If a warning is causing iPython to hang, there is something seriously wrong with iPython. A warning is just a message written to stderr, it doesn't affect the execution of the program. The json module does not natively support datetime, so whatever is happening, it is being triggered by non-stdlib code (probably a json subclass in the vcs package you are working with). I suggest you pursue this with the community that originated the vcs package. |
In case it wasn't clear: I seriously doubt that iPython is hanging due to the warning, I think something else must be happening and the warning is a red herring. |
@r.david.murray, rather than just closing this issue (which appears to be occurring intermittently for other users), is there a doc that you can point to that describes why there is a DeprecationWarning being printed - and what change has occurred (and when) that has led to my issue. It seems that jupyter notebooks are suffering the same problem, so I agree it's a non-standard lib issue, however some further assistance in resolving this issue by suggesting where to look would be helpful |
I also wonder whether the fact that the warnings library doesn't seems to be catching these errors when In [2]: import warnings Is being used is a similar issue - it seems something is falling through the cracks here |
I don't believe that warning message is generated by the python standard library. I can't find it in the codebase, and I can't think of any context in which we'd have a reason to generate that message. |
As for the filterwarnings, If you can come up with a demonstration of a problem that does not involve third party code, please open a new issue with the reproducer. |
@r.david.murray, is this not the stdlib? https://github.com/python/cpython/blob/master/Lib/json/encoder.py#L182-L202 The error message appears to be pointing back to this, how (and why) it gets there (and what has changed recently so that this DeprecationWarning is being triggered) is the question that I am seeking answers.. |
Yes, but the way deprecation warnings work is that there is a stacklevel specified, and the line reported in the error is that number of steps back up the call stack from where the warning was actually issued. The json module doesn't natively handle datetime, so there *must* be third party code that is doing the datetime encoding. It is that code that is triggering the Deprecation warning, and the stacklevel on that deprecation warning must skip the third party code and go up another level to land in the encode.py file. (self.iterencode can result in a call out to user code.) This may or may not be a bug in the third party DeprecationWarning...it is sometimes hard to get stacklevel right for all cases, especially if the code in question is usually called from a nested function inside the library. |
@r.david.murray fair enough, so it's an external lib that is the problem.. It does appear that similar issues have been appearing fairly recently across the github-o-sphere, some of these instances are listed at jupyter/jupyter#253 (comment) I've managed to solve my usability problem by commenting out a Thanks for taking the time to educate me |
I thought something like that might be the problem with your attempt to suppress the warnings. A library really should not call a global state function such as filterwarnings, that should be done only by the application. You might want to file a bug report with them about that. |
@r.david.murray, yep one step ahead of your last comment feel free to chime in if you think something else would be useful to highlight |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: