If you’re interested in trying httpx you’d be very welcome to raise an issue an issue related to NTLM/Negotiate authentication - it’d be really helpful for us to work through that and figure out if our auth API is sufficient for implementing that, or if there’s anything we’re missing.
* You can absolutely stay within structured concurrency constraints using ASGI.
* The ASGI spec doesn’t have anything to do with asyncio. It’s purely an async/await interface - You can build against it just fine using other concurrency backends.
I was dissapointed that the article didn't get into any details about the HTTP-level differences, but I think that's basically because they didn't need to know or care about the transport at that level since they were using Google's "cronet" library to dispatch the requests, and Google Cloud Load balancers as the QUIC termination point, so nothing on their ends actually deals with the neccessary differences from HTTP/2.
There's a pretty good reason there's a lot of folks building new frameworks for Python in this space right now: async.
Unlike WSGI frameworks we're now able to support WebSockets, lightweight backgrounds tasks, super-high-throughput performance, and all sorts of other goodies, that Flask, Django et al. aren't necessarily able to excel in.
Good news is that it's pretty likely that some of this may eventually feedback into Django, Flask, and others, but in the meantime it's a case of trying to bring the Python async ecosystem up to feature-parity with existing thread-concurrency frameworks as quickly as we possibly can.
Python is a hugely productive language. That's the benefit.
We're building out an async ecosystem here that makes it way more performance-competitive with Node and Go.
For a lot of folks it's going to hit a sweet spot of developer productivity plus ability to scale up hugely. That's a big deal.
Doesn't mean you have to use it, but there's no need to neg on the great work folks are doing in this space just because Python's not your preferred language of choice.
Just wanted to second @tiangolo's "Thanks for paving the way with Hug" - Absolutely yup! It's a lovely bit of interface design - definitely had a really positive impact on the space.
Authorship is always both an individual and a collective act of creativity. We've millenia of shared culture poured into us. Similarly the interplay between the feminine and the masculine voice: Each can only exists in contrast to the other, and we all have elements of both voices within.
There are 3 ASGI servers right now. Daphne, Uvicorn, Hypercorn.
For production deployments you’ll either want to run them with a supervisor process like supervisors/circus/etc. Or use gunicorn (uvicorn includes a gunicorn worker class).
Yo. Yeah my (bit of) involvement is mostly around wanting to help guide the new ASGI ecosystem.
For example, I'd like to see Python's async frameworks building on ASGI middleware rather than all re-writing their own middleware APIs. That way we end up with lots of cross-framework compatible middleware implementations, and we're all working together much more coherently.
Similarly for test clients. We don't really need frameworks to all be building their own individual test clients to interact against their own interfaces, when we can instead build test clients to interface against ASGI, and then be able to use them against any ASGI framework.
That's part of what the Starlette project (which Responder uses) is all about: https://www.starlette.io/
(FWIW Starlette also composes all those bits and pieces into a framework in its own right)
It really shouldn't be. It's a pragmatic question, based on what the likely outcomes and benefits or harms would be for deregulation.
> second of all it is a maturing experience.
Psychedelics put you at far higher risk of experiencing psychosis and other mental health issues. Don't rose-tint it as "maturing experience". You might not have an adverse response. Plenty have.
I think TechEmpower are doing a great job on these generally, but the plaintext benchmark is problematic because they allow pipelining. (Which isn’t enabled in browsers, isn’t typically used in request libraries and tools, and has generally been sidelined) Frameworks which are tailored with that in place can get a big boost in the ratings there.
If you want a measure of plain request/response I’d use the JSON benchmarks as the baseline.
You’ll get new calls into the application on new requests, yes. Request bodies are pulled tho.
You can perfectly well ensure that server implementations properly handle flow control, and if necessary also have a configurable number of maximum concurrent requests.
Either way, those sorts of concerns would be far better addressed by having server implementations against a common interface, than by framework authors having to handle (and continually re-implement) the nitty gritty details of high/low watermarks and pausing/resuming transports.
One thing I've never been able to reconcile is Mike Bayer's article there, set against Yury Selivanov's reported results for `asyncpg`, which at least as they're presented do indicate a significant difference in throughput.
They're both incredibly experienced developers, and I don't have any good steer on the discrepancy.
Would love to see some independent benchmarking on a typical use case to get a clearer picture on how valuable (or not) asyncio is for high-throughput database operations.
Neat, good to see more `asyncio` frameworks coming along.
Python's going to have a bit of an awkward time with two completely different sets of ecosystem for threaded vs. asyncio approaches, but it's necessary progress.
One thing I'd be really keen to see is asyncio frameworks starting to consider adopting ASGI as a common interface. Each of quart, sanic, aiohttp currently all have their own gunicorn worker classes, http parsing, and none share the same common interface for handling the request/response interface between server and application.
It's a really high barrier to new asyncio frameworks, and it means we're not able to get shared middleware, such as WSGI's whitenoise or Werkzeug debugger, or the increased robustness that shared server implementations would tend to result in.
Would be interested to know what OP's position on this is?
If you’re interested in trying httpx you’d be very welcome to raise an issue an issue related to NTLM/Negotiate authentication - it’d be really helpful for us to work through that and figure out if our auth API is sufficient for implementing that, or if there’s anything we’re missing.