ilusha/cpython
1
0
Fork 0
mirror of https://github.com/python/cpython synced 2026-09-29 08:45:29 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update the What's New details for importlib based on doc/ABC changes.

Browse source
This commit is contained in:
Brett Cannon 2012-08-02 17:50:06 -04:00
parent 773468f3a9
commit 077ef45a74
2 changed files with 25 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

10
Doc/library/importlib.rst
View file

@ -141,9 +141,10 @@ are also provided to help in implementing the core ABCs.
longer requires implementation of a ``find_module()`` method.
.. class:: MetaPathFinder(Finder)
.. class:: MetaPathFinder
An abstract base class representing a :term:`meta path finder`.
An abstract base class representing a :term:`meta path finder` and
inheriting from :class:`Finder`.
.. versionadded:: 3.3
@ -156,9 +157,10 @@ are also provided to help in implementing the core ABCs.
package. If a loader cannot be found, ``None`` is returned.
.. class:: PathEntryFinder(Finder)
.. class:: PathEntryFinder
An abstract base class representing a :term:`path entry finder`.
An abstract base class representing a :term:`path entry finder` and
inheriting from :class:`Finder`.
.. versionadded:: 3.3

24
Doc/whatsnew/3.3.rst
View file

@ -519,7 +519,15 @@ One of the large benefits of this work is the exposure of what goes into
making the import statement work. That means the various importers that were
once implicit are now fully exposed as part of the :mod:`importlib` package.
In terms of finders, * :class:`importlib.machinery.FileFinder` exposes the
The abstract base classes defined in :mod:`importlib.abc` have been expanded
to properly delineate between :term:`meta path finders <meta path finder>`
and :term:`path entry finders <path entry finder>` by introducing
:class:`importlib.abc.MetaPathFinder` and
:class:`importlib.abc.PathEntryFinder`, respectively. The old ABC of
:class:`importlib.abc.Finder` is now only provided for backwards-compatibility
and does not enforce any method requirements.
In terms of finders, :class:`importlib.machinery.FileFinder` exposes the
mechanism used to search for source and bytecode files of a module. Previously
this class was an implicit member of :attr:`sys.path_hooks`.
@ -547,10 +555,10 @@ section]
Beyond the expanse of what :mod:`importlib` now exposes, there are other
visible changes to import. The biggest is that :attr:`sys.meta_path` and
:attr:`sys.path_hooks` now store all of the finders used by import explicitly.
Previously the finders were implicit and hidden within the C code of import
instead of being directly exposed. This means that one can now easily remove or
change the order of the various finders to fit one's needs.
:attr:`sys.path_hooks` now store all of the meta path finders and path entry
hooks used by import. Previously the finders were implicit and hidden within
the C code of import instead of being directly exposed. This means that one can
now easily remove or change the order of the various finders to fit one's needs.
Another change is that all modules have a ``__loader__`` attribute, storing the
loader used to create the module. :pep:`302` has been updated to make this
@ -1733,6 +1741,12 @@ Porting Python code
both the modification time and size of the source file the bytecode file was
compiled from.
* :class:`importlib.abc.Finder` no longer specifies a `find_module()` abstract
method that must be implemented. If you were relying on subclasses to
implement that method, make sure to check for the method's existence first.
You will probably want to check for `find_loader()` first, though, in the
case of working with :term:`path entry finders <path entry finder>`.
* :mod:`pkgutil` has been converted to use :mod:`importlib` internally. This
eliminates many edge cases where the old behaviour of the PEP 302 import
emulation failed to match the behaviour of the real import system. The