Eric Snow added the comment: I'm glad you spoke up, Nick. Holding off on the DeprecationWarnings is fine with me. It's not like we are going to drop support for the APIs before Python 4! That said, DeprecationWarnings are disabled by default. So how big a deal do you think it is to leave the warnings in (minus loader.load_module)? I simply don't have a sense of how often people would be running with all warnings enabled (and not want that to let them know about these deprecations).
The latest patch already yanks most of the load_module() warnings. It had slipped my mind in the first patch. Of the warnings that are left, I'd still like to leave them in for: * importlib.find_loader() * NamespaceLoader (still not sure what to think about that class) * loader.module_repr() (if I can figure out a good way to make it work) since it will end up being a 3.3-only feature * importlib.util.set_loader() * importlib.util.set_package() That basically leaves removing warnings for finders (and maybe one or two others I missed): * finder.find_module() * finder.find_loader() As I said, I'm fine with doing so (or even pulling all the warnings). I simply thought of the warnings as a service to Python users to make them aware of the deprecations if they chose to check. However, I haven't been doing this nearly as long as you. :) So I'll readily concede that I may be missing something. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19713> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
