various typo fixes
This commit is contained in:
parent
80b2689335
commit
48f7cdd016
6 changed files with 18 additions and 18 deletions
|
|
@ -37,7 +37,7 @@ context local.
|
|||
Purpose of the Application Context
|
||||
----------------------------------
|
||||
|
||||
The main reason for the application's context existance is that in the
|
||||
The main reason for the application's context existence is that in the
|
||||
past a bunch of functionality was attached to the request context in lack
|
||||
of a better solution. Since one of the pillar's of Flask's design is that
|
||||
you can have more than one application in the same Python process.
|
||||
|
|
@ -58,7 +58,7 @@ Creating an Application Context
|
|||
To make an application context there are two ways. The first one is the
|
||||
implicit one: whenever a request context is pushed, an application context
|
||||
will be created alongside if this is necessary. As a result of that, you
|
||||
can ignore the existance of the application context unless you need it.
|
||||
can ignore the existence of the application context unless you need it.
|
||||
|
||||
The second way is the explicit way using the
|
||||
:meth:`~flask.Flask.app_context` method::
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ Manual Error Handler Attaching
|
|||
|
||||
While it is still possible to attach error handlers to
|
||||
:attr:`Flask.error_handlers` it's discouraged to do so and in fact
|
||||
deprecated. In generaly we no longer recommend custom error handler
|
||||
deprecated. In generally we no longer recommend custom error handler
|
||||
attaching via assignments to the underlying dictionary due to the more
|
||||
complex internal handling to support arbitrary exception classes and
|
||||
blueprints. See :meth:`Flask.errorhandler` for more information.
|
||||
|
|
|
|||
18
flask/app.py
18
flask/app.py
|
|
@ -541,8 +541,8 @@ class Flask(_PackageBoundObject):
|
|||
Here some examples::
|
||||
|
||||
app.logger.debug('A value for debugging')
|
||||
app.logger.warning('A warning ocurred (%d apples)', 42)
|
||||
app.logger.error('An error occoured')
|
||||
app.logger.warning('A warning occurred (%d apples)', 42)
|
||||
app.logger.error('An error occurred')
|
||||
|
||||
.. versionadded:: 0.3
|
||||
"""
|
||||
|
|
@ -846,7 +846,7 @@ class Flask(_PackageBoundObject):
|
|||
first_registration = False
|
||||
if blueprint.name in self.blueprints:
|
||||
assert self.blueprints[blueprint.name] is blueprint, \
|
||||
'A blueprint\'s name collision ocurred between %r and ' \
|
||||
'A blueprint\'s name collision occurred between %r and ' \
|
||||
'%r. Both share the same name "%s". Blueprints that ' \
|
||||
'are created on the fly need unique names.' % \
|
||||
(blueprint, self.blueprints[blueprint.name], blueprint.name)
|
||||
|
|
@ -1108,7 +1108,7 @@ class Flask(_PackageBoundObject):
|
|||
a new response object or the same (see :meth:`process_response`).
|
||||
|
||||
As of Flask 0.7 this function might not be executed at the end of the
|
||||
request in case an unhandled exception ocurred.
|
||||
request in case an unhandled exception occurred.
|
||||
"""
|
||||
self.after_request_funcs.setdefault(None, []).append(f)
|
||||
return f
|
||||
|
|
@ -1132,10 +1132,10 @@ class Flask(_PackageBoundObject):
|
|||
stack of active contexts. This becomes relevant if you are using
|
||||
such constructs in tests.
|
||||
|
||||
Generally teardown functions must take every necesary step to avoid
|
||||
Generally teardown functions must take every necessary step to avoid
|
||||
that they will fail. If they do execute code that might fail they
|
||||
will have to surround the execution of these code by try/except
|
||||
statements and log ocurring errors.
|
||||
statements and log occurring errors.
|
||||
|
||||
When a teardown function was called because of a exception it will
|
||||
be passed an error object.
|
||||
|
|
@ -1265,7 +1265,7 @@ class Flask(_PackageBoundObject):
|
|||
|
||||
def handle_exception(self, e):
|
||||
"""Default exception handling that kicks in when an exception
|
||||
occours that is not caught. In debug mode the exception will
|
||||
occurs that is not caught. In debug mode the exception will
|
||||
be re-raised immediately, otherwise it is logged and the handler
|
||||
for a 500 internal server error is used. If no such handler
|
||||
exists, a default 500 internal server error message is displayed.
|
||||
|
|
@ -1522,7 +1522,7 @@ class Flask(_PackageBoundObject):
|
|||
request handling is stopped.
|
||||
|
||||
This also triggers the :meth:`url_value_processor` functions before
|
||||
the actualy :meth:`before_request` functions are called.
|
||||
the actually :meth:`before_request` functions are called.
|
||||
"""
|
||||
bp = _request_ctx_stack.top.request.blueprint
|
||||
|
||||
|
|
@ -1675,7 +1675,7 @@ class Flask(_PackageBoundObject):
|
|||
The behavior of the before and after request callbacks was changed
|
||||
under error conditions and a new callback was added that will
|
||||
always execute at the end of the request, independent on if an
|
||||
error ocurred or not. See :ref:`callbacks-and-errors`.
|
||||
error occurred or not. See :ref:`callbacks-and-errors`.
|
||||
|
||||
:param environ: a WSGI environment
|
||||
:param start_response: a callable accepting a status code,
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ class ExtensionImporter(object):
|
|||
if module_name == important_module:
|
||||
return True
|
||||
|
||||
# Some python verisons will will clean up modules so early that the
|
||||
# Some python versions will will clean up modules so early that the
|
||||
# module name at that point is no longer set. Try guessing from
|
||||
# the filename then.
|
||||
filename = os.path.abspath(tb.tb_frame.f_code.co_filename)
|
||||
|
|
|
|||
|
|
@ -18,14 +18,14 @@ from flask.testsuite import FlaskTestCase
|
|||
|
||||
class FlaskSubclassingTestCase(FlaskTestCase):
|
||||
|
||||
def test_supressed_exception_logging(self):
|
||||
class SupressedFlask(flask.Flask):
|
||||
def test_suppressed_exception_logging(self):
|
||||
class SuppressedFlask(flask.Flask):
|
||||
def log_exception(self, exc_info):
|
||||
pass
|
||||
|
||||
out = StringIO()
|
||||
app = SupressedFlask(__name__)
|
||||
app.logger_name = 'flask_tests/test_supressed_exception_logging'
|
||||
app = SuppressedFlask(__name__)
|
||||
app.logger_name = 'flask_tests/test_suppressed_exception_logging'
|
||||
app.logger.addHandler(StreamHandler(out))
|
||||
|
||||
@app.route('/')
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ class Request(RequestBase):
|
|||
|
||||
def on_json_loading_failed(self, e):
|
||||
"""Called if decoding of the JSON data failed. The return value of
|
||||
this method is used by :attr:`json` when an error ocurred. The default
|
||||
this method is used by :attr:`json` when an error occurred. The default
|
||||
implementation raises a :class:`JSONBadRequest`, which is a subclass of
|
||||
:class:`~werkzeug.exceptions.BadRequest` which sets the
|
||||
``Content-Type`` to ``application/json`` and provides a JSON-formatted
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue