[issue19939] Deprecate portions or all of pkgutil module.

Brett Cannon added the comment: I think programmatic deprecation is actually fine since that only comes up when running under -W which would be a bit odd for any tool to be run under except when testing. E.g. I had no personal issue deprecating imp for Python 3.4 even though that's the only wa

[issue19939] Deprecate portions or all of pkgutil module.

Nick Coghlan added the comment: Programmatic deprecation definitely isn't worth it - setuptools et al need this for cross-version compatibility with 2.x, and packaging tools are hard enough to write without us programatically deprecating things in 3.x releases. Explicit documented deprecations

[issue19939] Deprecate portions or all of pkgutil module.

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue19939] Deprecate portions or all of pkgutil module.

New submission from Eric Snow: In the last Python releases, particularly 3.3 and 3.4, we've made improvements to the import machinery that render (at least) portions of pkgutil obsolete. Here's a breakdown of the public API of pkgutil: get_importer() - duplicate of PathFinder._path_importer_c