[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: @r.david.murray, yep one step ahead of your last comment https://github.com/UV-CDAT/vcs/issues/170#issuecomment-294219991 feel free to chime in if you think something else would be useful to highlight -- ___ Python

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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

[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: @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

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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

[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: @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

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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. -- ___ Python tracker

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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. -- ___

[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: I also wonder whether the fact that the warnings library doesn't seems to be catching these errors when In [2]: import warnings ...: warnings.filterwarnings('ignore', category=DeprecationWarning) In [3]: import vcs

[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: @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)

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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. -- ___ Python tracker

[issue30063] DeprecationWarning in json/encoder.py

R. David Murray added the comment: 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

[issue30063] DeprecationWarning in json/encoder.py

Paul Durack added the comment: I have attempted to quieten these using: In [2]: import warnings ...: warnings.filterwarnings('ignore', category=DeprecationWarning) In [3]: import vcs /home/user/anaconda2/envs/cdatcmornclnco/lib/python2.7/json/encoder.py:207: DeprecationWarning: Interpreting

[issue30063] DeprecationWarning in json/encoder.py

New submission from Paul Durack: 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