Permalink
Browse files

fixed spelling of "instantiate"

while the interwebs suggest "instanciate" might be a valid spelling, it
seems quite uncommon and potentially irritating (to pedants like myself)
  • Loading branch information...
1 parent b786eac commit 76c1a1f7227ca13f3c5952b248af93b75e9a95c9 FND committed Jan 23, 2012
Showing with 4 additions and 4 deletions.
  1. +1 −1 docs/patterns/appdispatch.rst
  2. +1 −1 docs/views.rst
  3. +2 −2 flask/views.py
@@ -58,7 +58,7 @@ Dispatch by Subdomain
Sometimes you might want to use multiple instances of the same application
with different configurations. Assuming the application is created inside
-a function and you can call that function to instanciate it, that is
+a function and you can call that function to instantiate it, that is
really easy to implement. In order to develop your application to support
creating new instances in functions have a look at the
:ref:`app-factories` pattern.
View
@@ -74,7 +74,7 @@ enough to explain the basic principle. When you have a class based view
the question comes up what `self` points to. The way this works is that
whenever the request is dispatched a new instance of the class is created
and the :meth:`~flask.views.View.dispatch_request` method is called with
-the parameters from the URL rule. The class itself is instanciated with
+the parameters from the URL rule. The class itself is instantiated with
the parameters passed to the :meth:`~flask.views.View.as_view` function.
For instance you can write a class like this::
View
@@ -72,7 +72,7 @@ def dispatch_request(self):
def as_view(cls, name, *class_args, **class_kwargs):
"""Converts the class into an actual view function that can be
used with the routing system. What it does internally is generating
- a function on the fly that will instanciate the :class:`View`
+ a function on the fly that will instantiate the :class:`View`
on each request and call the :meth:`dispatch_request` method on it.
The arguments passed to :meth:`as_view` are forwarded to the
@@ -90,7 +90,7 @@ def view(*args, **kwargs):
# we attach the view class to the view function for two reasons:
# first of all it allows us to easily figure out what class based
- # view this thing came from, secondly it's also used for instanciating
+ # view this thing came from, secondly it's also used for instantiating
# the view class so you can actually replace it with something else
# for testing purposes and debugging.
view.view_class = cls

0 comments on commit 76c1a1f

Please sign in to comment.