Php has its “p”falcon project too:

https://phalconphp.com/en/

Each night before bed I hope this project EOLs.

Having never looked at it.. why? Is it particularly bad in some way?

I see no problem here.

Different languages, different frameworks. There is no namespace collision.

It's a shame neither of those Falcons made it here

https://www.techempower.com/benchmarks/

They list the Python Falcon variant in their filters, and it used to be up there in previous editions.

it would be cool since this is claiming high performance

Yeah one of the first things I do when I want to make a project is google the name to see what is using it already. If its too popular or too close to what I am solving I dont use the name. Reminds me of that WAMP Protocol (which I found a stupid name cause the acronym already says protocol at the last P) which collided with WAMP the Windows Apache MySQL PHP project. The engineer apparently didnt care. I wish engineers would stop to think because poor naming could ruin a project or product.

Looks like it's a common theme among web frameworks: ASP.NET Core has Kestrel, i.e. small falcon.

Naming things is hard.

Not if you google "falcon http"

I always assumed in this case that it was due to Monty Python rather than anything else (I.e. the prevalence of Falcon-name-themed high-performance frameworks is due to Monty Python).

Can you explain the reference?

Indeed. Additionally, not take anything away from the Ruby counter part, the Python project is amazing and we use it in production. I really prefer the endpoint and viewmethod declaration methods in Falcon over Flask

    # In this example, I use blueprint plugin
    @bp.route('/', methods=['PUT'])
    def create_resource():
        return

vs

    class Resource(...):
        def on_put(self, request, response):
            return

Mirror: https://pastebin.com/50W8TJV2

Flask's hooking logic [1] is nice but I much prefer Falcon's middleware logic [2]. This then ties into the fact that Flask's design requires working with `g` [3] (essentially a global object) where as the middleware design leads us to bake in data in the request object. The example blow demonstrates how middleware definition works and how "adding data" per request works in both of these frameworks.

    # Flask; assuume `app` exists
    from flask import g
    @app.before_request
    def before_request():
        g.some_variable = 'foobar'

vs

    class ExampleComponent(object):
        def process_request(self, req, resp):
            req.some_variable = 'foobar'

Mirror: https://pastebin.com/Z3yGCfzF

Additionally, Falcon middleware API also exposes `process_resource` which is similar to above but also allows us to _pass_ arguments to the routed resource instance.

[1] http://flask.pocoo.org/docs/1.0/api/#flask.Flask.before_requ...

[2] https://falcon.readthedocs.io/en/stable/api/middleware.html

[3] http://flask.pocoo.org/docs/1.0/appcontext/#storing-data

Edit: Formatting