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_cache() iter_importers() - yields the path entry finder for each path entry find_loader() - a parent-importing wrapper around (deprecated) importlib.find_loader() get_loader() - looks at module.__loader__ or calls find_loader() walk_packages() - loader-focused iter_modules() - loader-focused get_data() - a wrapper around the InspectLoader.get_data() API read_code() - duplicates importlib functionality extend_path() - no longer needed (namespace packages) ImpImporter - already deprecated in favor of importlib ImpLoader - already deprecated in favor of importlib I would expect that nearly all of the module could be deprecated and any gaps in functionality ported to importlib.util. Is it worth it to go to the effort? To me the biggest thing would be identifying what functionality (e.g. locating all packages within a directory) in pkgutil is still relevant and should be distilled into public APIs in importlib. The job of actually deprecating and porting code would mostly be mechanical and not even a large amount of work. ---------- components: Library (Lib) messages: 205771 nosy: brett.cannon, eric.snow, ncoghlan, pje priority: normal severity: normal stage: needs patch status: open title: Deprecate portions or all of pkgutil module. type: enhancement versions: Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19939> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
