Fix a few typos (#250)

* Fix a few typos

* Spell, grammar checkers on docs
This commit is contained in:
Bruno P. Kinoshita 2020-06-14 14:24:32 +12:00 committed by GitHub
parent fac768496e
commit 910dec38a4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 22 additions and 22 deletions

View File

@ -3,7 +3,7 @@ Bundles mini application example
.. currentmodule:: dependency_injector.containers .. currentmodule:: dependency_injector.containers
"Bundles" is an example mini application that is intented to demonstrate the "Bundles" is an example mini application that is intended to demonstrate the
power of dependency injection for creation of re-usable application components power of dependency injection for creation of re-usable application components
("bundles") with 100% transparency of their dependencies. ("bundles") with 100% transparency of their dependencies.
@ -33,7 +33,7 @@ IoC containers
Next two listings show :py:class:`DeclarativeContainer`'s for "users" and Next two listings show :py:class:`DeclarativeContainer`'s for "users" and
"photos" bundles. "photos" bundles.
Listing of ``bundeles/users/__init__.py``: Listing of ``bundles/users/__init__.py``:
.. literalinclude:: ../../examples/miniapps/bundles/bundles/users/__init__.py .. literalinclude:: ../../examples/miniapps/bundles/bundles/users/__init__.py
:language: python :language: python
@ -43,7 +43,7 @@ Listing of ``bundeles/users/__init__.py``:
- ``Users`` container has dependency on database. - ``Users`` container has dependency on database.
Listing of ``bundeles/photos/__init__.py``: Listing of ``bundles/photos/__init__.py``:
.. literalinclude:: ../../examples/miniapps/bundles/bundles/photos/__init__.py .. literalinclude:: ../../examples/miniapps/bundles/bundles/photos/__init__.py
:language: python :language: python

View File

@ -77,7 +77,7 @@ definitely quite lower than in other languages (even with dynamic typing).
supported. supported.
Talking about inversion of control, it is a software design principle that Talking about inversion of control, it is a software design principle that
also works for each programming language, not dependending on its typing type. also works for each programming language, not depending on its typing type.
Inversion of control is used to increase modularity of the program and make Inversion of control is used to increase modularity of the program and make
it extensible. it extensible.

View File

@ -322,7 +322,7 @@ follows `Semantic versioning`_
3.3.7 3.3.7
----- -----
- Fix minor bug related to patch of ``Configuration`` provider in version - Fix minor bug related to patch of ``Configuration`` provider in version
3.3.6 - special attribues were identified by formula ``__{text}`` - now 3.3.6 - special attributes were identified by formula ``__{text}`` - now
they are identified by formula ``__{text}__``, that is more correct they are identified by formula ``__{text}__``, that is more correct
according to Python Data Model. according to Python Data Model.
@ -453,12 +453,12 @@ follows `Semantic versioning`_
- **Containers** - **Containers**
1. Module ``dependency_injector.containers`` was splitted into submodules 1. Module ``dependency_injector.containers`` was split into submodules
without any functional changes. without any functional changes.
- **Utils** - **Utils**
1. Module ``dependency_injector.utils`` is splitted into 1. Module ``dependency_injector.utils`` is split into
``dependency_injector.containers`` and ``dependency_injector.providers``. ``dependency_injector.containers`` and ``dependency_injector.providers``.
- **Miscellaneous** - **Miscellaneous**
@ -805,9 +805,9 @@ to be the first major release.
``Provider._provide()``. ``Provider._provide()``.
- ``NewInstance`` provider was renamed to ``Factory`` provider. - ``NewInstance`` provider was renamed to ``Factory`` provider.
``NewInstance`` still can be used, but it considered to be deprecated and ``NewInstance`` still can be used, but it considered to be deprecated and
will be removed in futher releases. will be removed in further releases.
- ``@inject`` decorator was refactored to keep all injections in - ``@inject`` decorator was refactored to keep all injections in
``_injections`` attribute of decorated callback. It will give a possibilty to ``_injections`` attribute of decorated callback. It will give a possibility to
track all the injections of particular callbacks and gives some performance track all the injections of particular callbacks and gives some performance
boost due minimizing number of calls for doing injections. boost due minimizing number of calls for doing injections.
- A lot of documentation updates were made. - A lot of documentation updates were made.

View File

@ -9,7 +9,7 @@ Below are some tips and recommendations that have to be met:
1. Every custom provider has to extend base provider class - 1. Every custom provider has to extend base provider class -
:py:class:`Provider`. :py:class:`Provider`.
2. Cusom provider's ``__init__()`` could be overriden, but parent's 2. Custom provider's ``__init__()`` could be overridden, but parent's
initializer (:py:meth:`Provider.__init__`) has to be called. initializer (:py:meth:`Provider.__init__`) has to be called.
3. Providing strategy has to be implemented in custom provider's 3. Providing strategy has to be implemented in custom provider's
:py:meth:`Provider.__call__` method. :py:meth:`Provider.__call__` method.

View File

@ -160,7 +160,7 @@ aggregates other :py:class:`Factory` providers.
:py:class:`FactoryAggregate` is not overridable. Calling of :py:class:`FactoryAggregate` is not overridable. Calling of
:py:meth:`FactoryAggregate.override` will result in raising of an :py:meth:`FactoryAggregate.override` will result in raising of an
expection. exception.
Next prototype might be the best demonstration of Next prototype might be the best demonstration of
:py:class:`FactoryAggregate` features: :py:class:`FactoryAggregate` features:

View File

@ -9,7 +9,7 @@ This gives opportunity to make system behaviour more flexible at some point.
The main feature is that while your code is using providers, it depends on The main feature is that while your code is using providers, it depends on
providers, but not on the objects that providers provide. As a result of this, providers, but not on the objects that providers provide. As a result of this,
you can change providing by provider object to a different one, but still you can change providing by provider object to a different one, but still
compatible one, without chaning your previously written code. compatible one, without changing your previously written code.
Provider overriding functionality has such interface: Provider overriding functionality has such interface:

View File

@ -22,11 +22,11 @@ Singleton providers resetting
Created and memorized by :py:class:`Singleton` instance can be reset. Reset of Created and memorized by :py:class:`Singleton` instance can be reset. Reset of
:py:class:`Singleton`'s memorized instance is done by clearing reference to :py:class:`Singleton`'s memorized instance is done by clearing reference to
it. Further lifecycle of memorized instance is out of :py:class:`Singleton` it. Further lifecycle of memorized instance is out of :py:class:`Singleton`
provider's control and dependes on garbage collection strategy. provider's control and depends on garbage collection strategy.
Example: Example:
.. literalinclude:: ../../examples/providers/singleton_reseting.py .. literalinclude:: ../../examples/providers/singleton_resetting.py
:language: python :language: python
:linenos: :linenos:

View File

@ -356,7 +356,7 @@ cdef class Dependency(Provider):
This provider is used for description of dependency interface. That might This provider is used for description of dependency interface. That might
be useful when dependency could be provided in the client's code only, be useful when dependency could be provided in the client's code only,
but it's interface is known. Such situations could happen when required but it's interface is known. Such situations could happen when required
dependency has non-determenistic list of dependencies itself. dependency has non-deterministic list of dependencies itself.
.. code-block:: python .. code-block:: python
@ -445,7 +445,7 @@ cdef class ExternalDependency(Dependency):
This provider is used for description of dependency interface. That might This provider is used for description of dependency interface. That might
be useful when dependency could be provided in the client's code only, be useful when dependency could be provided in the client's code only,
but it's interface is known. Such situations could happen when required but it's interface is known. Such situations could happen when required
dependency has non-determenistic list of dependencies itself. dependency has non-deterministic list of dependencies itself.
.. code-block:: python .. code-block:: python
@ -607,7 +607,7 @@ cdef class OverridingContext(object):
"""Provider overriding context. """Provider overriding context.
:py:class:`OverridingContext` is used by :py:meth:`Provider.override` for :py:class:`OverridingContext` is used by :py:meth:`Provider.override` for
implemeting ``with`` contexts. When :py:class:`OverridingContext` is implementing ``with`` contexts. When :py:class:`OverridingContext` is
closed, overriding that was created in this context is dropped also. closed, overriding that was created in this context is dropped also.
.. code-block:: python .. code-block:: python
@ -739,7 +739,7 @@ cdef class Callable(Provider):
return self return self
def set_args(self, *args): def set_args(self, *args):
"""Set postional argument injections. """Set positional argument injections.
Existing positional argument injections are dropped. Existing positional argument injections are dropped.
@ -750,7 +750,7 @@ cdef class Callable(Provider):
return self return self
def clear_args(self): def clear_args(self):
"""Drop postional argument injections. """Drop positional argument injections.
:return: Reference ``self`` :return: Reference ``self``
""" """
@ -1272,7 +1272,7 @@ cdef class Factory(Provider):
return self.__instantiator.args return self.__instantiator.args
def add_args(self, *args): def add_args(self, *args):
"""Add __init__ postional argument injections. """Add __init__ positional argument injections.
:return: Reference ``self`` :return: Reference ``self``
""" """
@ -1280,7 +1280,7 @@ cdef class Factory(Provider):
return self return self
def set_args(self, *args): def set_args(self, *args):
"""Set __init__ postional argument injections. """Set __init__ positional argument injections.
Existing __init__ positional argument injections are dropped. Existing __init__ positional argument injections are dropped.
@ -1290,7 +1290,7 @@ cdef class Factory(Provider):
return self return self
def clear_args(self): def clear_args(self):
"""Drop __init__ postional argument injections. """Drop __init__ positional argument injections.
:return: Reference ``self`` :return: Reference ``self``
""" """