mirror of https://github.com/python/cpython
Docs: fix typos in documentation (GH-118815)
This commit is contained in:
parent
46c808172f
commit
17a2cc199d
|
@ -1252,7 +1252,7 @@ find and load modules.
|
|||
be only a single binary per framework, and there can be no executable binary
|
||||
material outside the Frameworks folder.
|
||||
|
||||
To accomodate this requirement, when running on iOS, extension module
|
||||
To accommodate this requirement, when running on iOS, extension module
|
||||
binaries are *not* packaged as ``.so`` files on ``sys.path``, but as
|
||||
individual standalone frameworks. To discover those frameworks, this loader
|
||||
is be registered against the ``.fwork`` file extension, with a ``.fwork``
|
||||
|
@ -1279,7 +1279,7 @@ find and load modules.
|
|||
|
||||
When a module is loaded with this loader, the ``__file__`` for the module
|
||||
will report as the location of the ``.fwork`` file. This allows code to use
|
||||
the ``__file__`` of a module as an anchor for file system traveral.
|
||||
the ``__file__`` of a module as an anchor for file system traversal.
|
||||
However, the spec origin will reference the location of the *actual* binary
|
||||
in the ``.framework`` folder.
|
||||
|
||||
|
|
|
@ -1204,7 +1204,7 @@ functions.
|
|||
most programs will want to carefully and explicitly control the logging
|
||||
configuration, and should therefore prefer creating a module-level logger and
|
||||
calling :meth:`Logger.debug` (or other level-specific methods) on it, as
|
||||
described at the beginnning of this documentation.
|
||||
described at the beginning of this documentation.
|
||||
|
||||
|
||||
.. function:: info(msg, *args, **kwargs)
|
||||
|
|
Loading…
Reference in New Issue