iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[PEP 451] Fix some typos.

This commit is contained in:
Eric Snow 2013-10-22 20:09:07 -06:00
parent 79f12c3388
commit 3cc4e26a24
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
pep-0451.txt
View File

@ -164,7 +164,7 @@ loaders and sys.meta_path. The importlib module, introduced
with Python 3.1, now exposes a pure Python implementation of the APIs with Python 3.1, now exposes a pure Python implementation of the APIs
described by PEP 302, as well as of the full import system. It is now described by PEP 302, as well as of the full import system. It is now
much easier to understand and extend the import system. While a benefit much easier to understand and extend the import system. While a benefit
to the Python community, this greater accessibilty also presents a to the Python community, this greater accessabilty also presents a
challenge. challenge.
As more developers come to understand and customize the import system, As more developers come to understand and customize the import system,
@ -188,7 +188,7 @@ functionality of their load_module() through other methods. Thus,
though the import-related information about a module is likely available though the import-related information about a module is likely available
without loading the module, it is not otherwise exposed. without loading the module, it is not otherwise exposed.
Furthermore, the requirements assocated with load_module() are Furthermore, the requirements associated with load_module() are
common to all loaders and mostly are implemented in exactly the same common to all loaders and mostly are implemented in exactly the same
way. This means every loader has to duplicate the same boilerplate way. This means every loader has to duplicate the same boilerplate
code. importlib.util provides some tools that help with this, but code. importlib.util provides some tools that help with this, but
@ -545,7 +545,8 @@ zipimport), that information may be stored in spec.loader_state.
"has_location" may be implied from the existence of a load_data() method "has_location" may be implied from the existence of a load_data() method
on the loader. on the loader.
Incidently, not all locatable modules will be cachable, but most will. Incidentally, not all locatable modules will be cache-able, but most
will.
**submodule_search_locations** **submodule_search_locations**
@ -587,7 +588,7 @@ Build a spec from file-oriented information and loader APIs.
not passed in. not passed in.
* "loader" can be deduced from suffix if the location is a filename. * "loader" can be deduced from suffix if the location is a filename.
* "submodule_search_locations" can be deduced from loader.is_package() * "submodule_search_locations" can be deduced from loader.is_package()
and from os.path.dirname(location) if locatin is a filename. and from os.path.dirname(location) if location is a filename.
**from_loader(name, loader, \*, origin=None, is_package=None)** **from_loader(name, loader, \*, origin=None, is_package=None)**
@ -596,7 +597,7 @@ Build a spec with missing information filled in by using loader APIs.
* "has_location" can be deduced from loader.get_data. * "has_location" can be deduced from loader.get_data.
* "origin" can be deduced from loader.get_filename(). * "origin" can be deduced from loader.get_filename().
* "submodule_search_locations" can be deduced from loader.is_package() * "submodule_search_locations" can be deduced from loader.is_package()
and from os.path.dirname(location) if locatin is a filename. and from os.path.dirname(location) if location is a filename.
**spec_from_module(module, loader=None)** **spec_from_module(module, loader=None)**