Spell, grammar checkers on docs

docs/examples/bundles_miniapp.rst

@@ -3,7 +3,7 @@ Bundles mini application example
 
 .. 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
 ("bundles") with 100% transparency of their dependencies.
 
@@ -33,7 +33,7 @@ IoC containers
 Next two listings show :py:class:`DeclarativeContainer`'s for "users" and 
 "photos" bundles.
 
-Listing of ``bundeles/users/__init__.py``:
+Listing of ``bundles/users/__init__.py``:
 
 .. literalinclude:: ../../examples/miniapps/bundles/bundles/users/__init__.py
    :language: python
@@ -43,7 +43,7 @@ Listing of ``bundeles/users/__init__.py``:
 
     - ``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
    :language: python

docs/introduction/di_in_python.rst

@@ -77,7 +77,7 @@ definitely quite lower than in other languages (even with dynamic typing).
     supported.
 
 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 
 it extensible.

docs/main/changelog.rst

@@ -322,7 +322,7 @@ follows `Semantic versioning`_
 3.3.7
 -----
 - 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
   according to Python Data Model.
 
@@ -453,12 +453,12 @@ follows `Semantic versioning`_
 
 - **Containers**
 
-  1. Module ``dependency_injector.containers`` was splitted into submodules 
+  1. Module ``dependency_injector.containers`` was split into submodules 
      without any functional changes.
 
 - **Utils**
 
-  1. Module ``dependency_injector.utils`` is splitted into 
+  1. Module ``dependency_injector.utils`` is split into 
      ``dependency_injector.containers`` and ``dependency_injector.providers``.
 
 - **Miscellaneous**
@@ -805,9 +805,9 @@ to be the first major release.
   ``Provider._provide()``.
 - ``NewInstance`` provider was renamed to ``Factory`` provider. 
   ``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 
-  ``_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 
   boost due minimizing number of calls for doing injections.
 - A lot of documentation updates were made.

docs/providers/custom.rst

@@ -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 - 
        :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.
     3. Providing strategy has to be implemented in custom provider's 
        :py:meth:`Provider.__call__` method.

docs/providers/factory.rst

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

docs/providers/overriding.rst

@@ -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 
 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
-compatible one, without chaning your previously written code.
+compatible one, without changing your previously written code.
 
 Provider overriding functionality has such interface:
 

docs/providers/singleton.rst

@@ -22,11 +22,11 @@ Singleton providers resetting
 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 
 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:
 
-.. literalinclude:: ../../examples/providers/singleton_reseting.py
+.. literalinclude:: ../../examples/providers/singleton_resetting.py
    :language: python
    :linenos: