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``
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.
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)