mirror of https://github.com/pallets/flask.git
Fix a few spelling mistakes in the docs
This commit is contained in:
parent
b57a076fa3
commit
8570633214
|
|
@ -30,7 +30,7 @@ at :func:`werkzeug.serving.run_simple`::
|
|||
Note that :func:`run_simple <werkzeug.serving.run_simple>` is not intended for
|
||||
use in production. Use a :ref:`full-blown WSGI server <deployment>`.
|
||||
|
||||
In order to use the interactive debuggger, debugging must be enabled both on
|
||||
In order to use the interactive debugger, debugging must be enabled both on
|
||||
the application and the simple server, here is the "hello world" example with
|
||||
debugging and :func:`run_simple <werkzeug.serving.run_simple>`::
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ that most libraries (including Werkzeug and Flask) might not quite as stable
|
|||
on Python 3 yet. You might therefore sometimes run into bugs that are
|
||||
usually encoding-related.
|
||||
|
||||
The majority of the upgrade pain is in the lower-level libararies like
|
||||
The majority of the upgrade pain is in the lower-level libraries like
|
||||
Flask and Werkzeug and not in the actual high-level application code. For
|
||||
instance all of the Flask examples that are in the Flask repository work
|
||||
out of the box on both 2.x and 3.x and did not require a single line of
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ but you can also continue using the :meth:`Flask.run` method.
|
|||
Command Line
|
||||
------------
|
||||
|
||||
The :command:`flask` command line script (:ref:`cli`) is strongly recommende for
|
||||
The :command:`flask` command line script (:ref:`cli`) is strongly recommended for
|
||||
development because it provides a superior reload experience due to how it
|
||||
loads the application. The basic usage is like this::
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Step 6: The Templates
|
||||
=====================
|
||||
|
||||
Now we should start working on the templates. If we were torequest the URLs
|
||||
Now we should start working on the templates. If we were to request the URLs
|
||||
now, we would only get an exception that Flask cannot find the templates. The
|
||||
templates are using `Jinja2`_ syntax and have autoescaping enabled by
|
||||
default. This means that unless you mark a value in the code with
|
||||
|
|
|
|||
|
|
@ -258,7 +258,7 @@ applications automatically, but there might be some cases where it fails
|
|||
to upgrade. What changed?
|
||||
|
||||
- Blueprints need explicit names. Modules had an automatic name
|
||||
guesssing scheme where the shortname for the module was taken from the
|
||||
guessing scheme where the shortname for the module was taken from the
|
||||
last part of the import module. The upgrade script tries to guess
|
||||
that name but it might fail as this information could change at
|
||||
runtime.
|
||||
|
|
@ -296,7 +296,7 @@ Flask 0.6 comes with a backwards incompatible change which affects the
|
|||
order of after-request handlers. Previously they were called in the order
|
||||
of the registration, now they are called in reverse order. This change
|
||||
was made so that Flask behaves more like people expected it to work and
|
||||
how other systems handle request pre- and postprocessing. If you
|
||||
how other systems handle request pre- and post-processing. If you
|
||||
depend on the order of execution of post-request functions, be sure to
|
||||
change the order.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue