Project direction for 2019

[btegs]

Moving into 2019, here are a few things I'd like to see with this project:

1. Try to end Python 2 support in a future version. I know Falcon 2.0 may be too soon, but maybe 3.0 is a good start as Python 2.7 is in maintenance mode and will not be maintained after 2020. Putting the project focus just on Python 3 will cut down on dependencies and developer resources. Maybe still update the 1.x or 2.x series with Python 2.7 support if people really really need it. Other successful frameworks like Japronto, Sanic, and Vibora have been fine with Python 3.5+.

2. Provide concise deployment instructions for the best performance on CPython, Cython, and PyPy. According to the official benchmarks page, you are able to hit over 500,000 requests a second when using PyPy as the backend. How are you doing this? It would be nice to have sample code, a list of all the packages installed, and especially the ASGI or UWSGI backend like gunicorn to achieve this. Documentation is king!!

3. How is support for asynchronous code in Python 3.5+ and supplementary tech like ASGI and uvloop? Other frameworks like Japronto, Sanic, and Vibora are utilizing uvloop and are doing it directly without using gunicorn externally. The github repo the-benchmarker has some up to date benchmarks comparing the Python frameworks to others.

4. This may not affect everyone, but I'm curious if I can write pure Cython code or utilize a .pxd file with standard Python to speed up my code. Falcon already takes advantage of Cython and if its possible to write my endpoints in Cython, would be nice to have some documentation in how to do that. Oh and its also stretching it in thinking of ways to make Falcon faster by using extensions written in Rust. I understand that its more of a ctypes/cffi thing, but I can only dream and throw that out there. ;-)

These are all I have for now. I have been using Falcon since 2014 and it has consistently been my favorite Python framework for various projects. Although I have been tempted by others like Japronto which offer raw speed at the cost of support by the developer, Falcon has been very active and it seems like the project leads do really want to see it succeed.

[kgriffs]

HI @btegs, thanks for sharing your thoughts and feedback. I'll share my own $0.02 here, and let the other maintainers chime in at their discretion.

1. Try to end Python 2 support in a future version.

We are currently driving hard toward a 2.0 release (see also #1390), and I'm happy to say that we actually just recently discussed (and decided on) keeping Python 2 for this release, but dropping support for it in 3.0. In fact, to accelerate the advent of 3.0, I am currently discussing with the other maintainers a plan for minimizing any 2.x work (after 2.0), while also keeping the 3.0 milestone issues list very short and focused (pushing non-breaking changes to subsequent 3.x releases as much as possible).

2. Provide concise deployment instructions for the best performance on CPython, Cython, and PyPy.

There are some docker containers that can be used to reproduce those published results, but how that all works is admittedly not explained well. I do think it would be worth a push during 2019 to improve our docs in a number of areas (as well as improving the benchmark suite itself; what is currently there was just designed to give people an inkling of what was possible with Python).

Regardless, myself and the other Falcon maintainers don't pretend to know all the best ways to do things, and so we will need additional contributors to step up from the community to share their experiences and insights.

3. How is support for asynchronous code in Python 3.5+ and supplementary tech like ASGI and uvloop?

There has been a lot of experimentation in this space over the past few years since the advent of native async support in CPython, which I think is a very good thing. However, the downside to all of this is that it has (and will) take a while for the community to identify best practices and coalesce around a somewhat stable, performant set of approaches.

To be honest, I think it would be a mistake to create yet another one-off web async interface implementation, especially if said implementation is tightly coupled to a specific library. This comes of my being a big fan of standards (which is why Falcon tries hard to comply closely with the IETF RFCs and the WSGI PEP).

With all of this in mind, I have been happy to see the progress that has been made with ASGI. After a discussion with hawkowl last year at PyCon, and a fair bit of subsequent prototyping and discussions between myself and another Falcon maintainer, I've become satisfied that the time is finally right to move forward with async in Falcon. Therefore, I'm happy to announce that we will be implementing ASGI for Falcon 3.0, which I'm hoping we can release in the second quarter of 2019. Our implementation will make it somewhat straightforward to port WSGI apps over, and we will support both WSGI and ASGI out of the box going forward.

4. This may not affect everyone, but I'm curious if I can write pure Cython code or utilize a .pxd file with standard Python to speed up my code.

I think that is a great idea; I'll add it to the list of documentation items to look at. We've actually been toying with the idea of implementing parts of Falcon itself in Cython (with a pure-python fallback). Re CFFI, it might not be a bad idea to document how to do that with Falcon as well, although you have to have a very expensive operation for it to make sense (so that your speedup is greater than the overhead of thunking across the boundary). I love me some PyPy, but their progress on keeping up with CPython is slower than I would like, and there are other obvious reasons beyond that, anyway, for having strong CPython support.

[btegs]

Thanks for the update Kurt! I'm glad that you have remained committed to this project over the years and keep improving it. Its a breath of fresh air compared to some other frameworks that are still very much alpha or have lost development entirely.

In response to your response, you mentioned the Docker containers. You currently have to login to a site to get the container and I was wondering if you could simply upload the docker file to this repo. If it is more complicated than that, then I understand. If not, would be a nice benefit.

I also share the love of PyPy, but worry about the progression of the project. It still works the best with the Python 2 version, but as we all know, Python 2 in general will be out the door. The Python 3 version lags behind feature and performance wise and I have no clue if they will do a 3.7 version or not. It is at 3.5 and even then, there are issues with some packages. That's why I have been looking to Cython instead as I can continue to use Python 3.7 and get the speed bump.

Thanks for being awesome and I look forward to tinkering with 2.0 in January!

[kgriffs]

Dropping a few links here for future reference:

• [Roadmap 2019] #1394
• [Umbrella] Better Docs! #1393
• https://github.com/falconry/falcon/milestone/33