The default JSONDecoder adds no extra functionality to `json.loads`, but using a custom class in the function call you off of an optimized fast path in pypy (it adds some overhead in cpython, but I think it's minimal). This change sticks with the default loading behaviour unless the user has specifically opted in to customising it.
Co-authored-by: David Lord <davidism@gmail.com>
Handlers registered via url_value_preprocessor, before_request,
context_processor, and url_defaults are called in downward order: First
on the app and last on the current blueprint.
Handlers registered via after_request and teardown_request are called
in upward order: First on the current blueprint and last on the app.
Previously the blueprint recorded aspects (before request, after
request etc) would only be added to the app if it was the first
registration of the blueprint instance. However only the record-once
aspects (app-before requests, app-after request) should be added once
on registration of the instance, whereas everything else should be
added on every unique name registration. This ensures that these
trigger under the new name as well as the old.
As long as popular libraries (e.g. Celery) require click 7, depending
on Click 8 in Flask makes it hard to test the latest version (and its
other dependencies) in existing applications.
This allows blueprints to be nested within blueprints via a new
Blueprint.register_blueprint method. This should provide a use case
that has been desired for the past ~10 years.
This works by setting the endpoint name to be the blueprint names,
from parent to child delimeted by "." and then iterating over the
blueprint names in reverse order in the app (from most specific to
most general). This means that the expectation of nesting a blueprint
within a nested blueprint is met.
