1. File structure:

project -
      - templates \
                - a \
                      search.html
                - b \
                      search.html
      - start.py
      - myapplication \
                - test.py 

1. Start file:

# start.py
from flask import Flask
from myapplication.test import test_blueprint

app = Flask(__name__)
app.register_blueprint(test_blueprint)

1. my application

# test.py
from flask import Blueprint, render_template, abort
from jinja2 import TemplateNotFound

test_blueprint = Blueprint('test_blueprint', __name__,
                        template_folder='absolute_path_to_project/templates/a')  
                        # YES, I specified the absolute path to the template a

@test_blueprint.route('/test')
def show():
    try:
        return render_template(''search.html") # HERE is the problem
    except TemplateNotFound:
        abort(404)

Is this a problem? # Actually, I want to render a/search.html # But, render_template() does not use test_blueprint's template_folder # render_template() search the template list, find the first search.html, then render # So, maybe render a/search.html or b/search.html # This depend on the sequence of the template list

What are the plans for the 1.0 release. This was brought up last year and there hasn't been any announcements since then. What progress is being made and what still remains?

L496 in helpers.py If i use flask as a package instead of a module, I want to expose a file which is not in package. checks in send_from_directory will be passed because of rel path. However, in send_file, added abs folder, it occur an error.

It looks like flask.json does not allow the user to specify an alternative json library (such as rapidjson). Instead it just does this:

try:
    from itsdangerous import simplejson as _json
except ImportError:
    from itsdangerous import json as _json

This currently un-overridable behavior also means that, due to differences in when default(..) is called between simplejson and json, bugs can mysteriously appear when simplejson is installed that didn't appear without it.

Would you consider giving the user some control over which json library is used?

Hi.

I've detected an issue with supporting unicode filenames in send_file. If send_file attempts to respond with utf-8 in http headers, the answer is empty, the log contains something like "http-headers should containbe latin-1". I know that browser support IS A MESS, but it seems, that sending two filenames (filename= and filename*=) separated by semicolon should work.

I'd like this to be handled by flask or werkzeug. Will you accept such pull request?

having 'example.com' and 'example.org' running on the same server with the same data backend I thought it would be simple to serve both from a single Flask app, especially since Werkzeug has host_matching but it isn't.

I currently workaround this by 'injecting' hostname into urls with nginx's url rewrites but this is a bit too hackish, you know.

I would like to have syntax like this:

@app.route("/", host="example.org")
def hello():
    return "Hello World!"

Message flashing as implemented in Flask is currently broken, under certain conditions it's possible for messages to be flashed to the wrong tab or in extreme cases the wrong device/browser.

A correct implementation would require functionality beyond Flask's scope, message flashing itself is arguably beyond Flask's scope already.

Why not make a piss-poor user account system that exists solely in session cookies? It seems like the same logic behind Flask's message flashing functionality.

I have been having issues for 3-4 days now to get a hello world up and running on the remote server. I figured out that it would be nice if there was a documentation from A-Z how to get that done and working.

http://flask.pocoo.org/docs/deploying/mod_wsgi/

The current documentation does not provide an example what to put into an exact python file, and what url to open up in the web browser to get the desired python module running on the remote server. It is okay to have references to other places if that is more logical, but the idea is to have a self-contained page which I can start reading, and by I reach the end, I will have a working remote hello world.

This would be well appreciated.

This will require Python 2 support to be dropped, which as I understand isn't likely to happen till 2020. Which is a bonus as it gives time to consider this change and the implications of it. (I also need to spend some time cleaning up this implementation, yet it serves as a proof of concept).

I've written this blog post to add some extra context, but I see a key aspect to this change is that whilst it adds async support it does not do so throughout and specifically does not support ASGI. This means that Flask is constrained (when using async) to have worse performance than the ASGI equivalents. This is necessary as I don't think Flask can be async throughout (or support ASGI) whilst being backwards compatible. Yet this change is good overall, in that users would be able to add some async usage to their existing codebases. I would also like to note that they can switch to Quart if their usage becomes mostly async.

This allows for async functions to be passed to the Flask class instance, for example as a view function,

@app.route("/")
async def index():
    return "Async hello"

this comes with a cost though of poorer performance than using the sync equivalent.

I'd like to be able to register "sub-blueprints" using Blueprint.register_blueprint(*args, **kwargs). This would register the nested blueprints with an app when the "parent" is registered with it. All parameters are preserved, other than url_prefix, which is handled similarly to in add_url_rule. A naíve implementation could look like this:

class Blueprint(object):
    ...

    def register_blueprint(self, blueprint, **options):
        def deferred(state):
            url_prefix = options.get('url_prefix')
            if url_prefix is None:
                url_prefix = blueprint.url_prefix
            if 'url_prefix' in options:
                del options['url_prefix']

            state.app.register_blueprint(blueprint, url_prefix, **options)
        self.record(deferred)

I don't have a good description for the issue yet but one of the issues I keep running into myself in 2017 is that it's not convenient to marry Flask and webpack. The issue here is that one wants to both have a server app as well as a client app and each uses a hot reloader for code.

There is a lot of boilerplate to make two services work and there is absolutely no support on the side of Flask to make it work. So here is what Flask most likely should do:

Environment Awareness

Flask needs to know about environments. For now I would propose to mirror the node model where we have an environment flag and depending on the environment flag some flags get flipped automatically. In development for instance we would turn on debug by default. This discourages apps to make too many assumptions about the debug flag but instead use an environment flag instead.

This means debug can be flipped on and off in development mode. A potential webpack integration extension can then forward that flag to webpack.

Proxy or be-proxied Capabilities

Right now one either needs front/backend to be running different servers on different ports or use some manual proxy setup to make this work. Right now the webpack server can pass through to the Flask server but it's quite hacky and non trivial.

In an ideal case Flask in development mode can spawn another process (like a webpack server, ngrok etc.) and manage this process. It would work independently of the Flask reloader but shut down together.

If it spawns a process on a different port Flask should itself be proxied through that other server or proxy to another server if that's easier. This would most likely require that the Werkzeug server learns HTTP proxying as we might not be able to do this on the WSGI level.

Bumps dessant/lock-threads from 3 to 4.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

To reproduce:

from flask import session

session.get("foo")

Produces a pyright/Pylance error in VSCode in strict typing mode:

Type of "get" is partially unknown
  Type of "get" is "Overload[(__key: Unknown, /) -> (Unknown | None), (__key: Unknown, /, default: Unknown | [email protected]) -> (Unknown | [email protected])]"Pylance[reportUnknownMemberType]

mypy --strict doesn't seem to mind, but it also accepts session.get({"a": 7}) without complaint, so perhaps not a good measure.

Changing the offending line like this fixes the problem:

cast(MutableMapping[str, Any], session).get("foo")

Based on this observation I changing this line in the SessionMixin declaration, which also fixes the problem: https://github.com/pallets/flask/blob/main/src/flask/sessions.py#L21

# --- from ---
class SessionMixin(MutableMapping):

# --- to ---
class SessionMixin(MutableMapping[t.Hashable, t.Any]):

I'm not sure if I've gotten those types exactly right, I believe they are the broadest possible types, but perhaps keys are limited to str or values could be narrowed.

Happy to submit a pull request if that's a help. Thanks so much for Flask, it is an immensely important contribution to the Python ecosystem I make my living in :)

Environment:

• Python version: 3.10.7
• Flask version: 2.2.2

The appcontext documentation should explain the new @setupmethod 'shell_context_process' behavior, linked to https://github.com/pallets/flask/pull/4577.

Flask raises an Assertion Error.

AssertionError: The setup method 'shell_context_processor' can no longer be called on the application. It has already handled its first request, any changes will not be applied consistently. Make sure all imports, decorators, functions, etc. needed to set up the application are done before running it.

The error should be documented, and a correct implementation should be provided.

When child blueprints are mounted onto parents, they don't inherit the subdomain set by the parent.

This PR ensures that routes in child blueprint will be available at the same subdomain set by the parent.

However, children can also specify their own subdomain if necessary.

• fixes #4834

Checklist:

• [x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• [x] Add or update relevant docs, in the docs folder and in code.
• [x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• [x] Add .. versionchanged:: entries in any relevant code docs.
• [x] Run pre-commit hooks and fix any issues.
• [x] Run pytest and tox, no tests failed.

Currently, the documentation says to replace celery.Task with a custom ContextTask. But this raises an error using mypy:

$ cat minimal.py 
from flask import Flask
from celery import Celery, Task

def make_celery(app: Flask):
    celery = Celery(app.import_name)
    celery.conf.update(app.config["CELERY_CONFIG"])

    class ContextTask(Task):
        def __call__(self, *args, **kwargs):
            with app.app_context():
                return self.run(*args, **kwargs)

    celery.Task = ContextTask
    return celery
$ mypy minimal.py
minimal.py:13: error: Property "Task" defined in "Celery" is read-only
minimal.py:13: error: Incompatible types in assignment (expression has type "Type[ContextTask]", variable has type "Task[Any]")

Instead one should initialize Celery with a string of the desired Task class. See Celery docs.

$ cat minimal.py 
from flask import Flask
from celery import Celery, Task


class ContextTask(Task):
    def __call__(self, *args, **kwargs):
        with app.app_context():
            return self.run(*args, **kwargs)


def make_celery(app: Flask):
    celery = Celery(app.import_name, task_cls="minimal.minimal:ContextTask")
    celery.conf.update(app.config["CELERY_CONFIG"])

    return celery
$ mypy minimal.py
Success: no issues found in 1 source file