2,252 karma · joined January 31, 2011
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.
It's for the best that it becomes widely treated as a non-feature of HTTP/1.1.
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.
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.
"Et nous sommes encor tout mêlés l’un à l’autre"
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).
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)
Using `x = [] if x is None else x` is more precise.
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.
For fast Web App development it's a superb language choice.
Not so good if you wanted to write a super-high-throughput proxy service, but asyncio & ASGI is starting to change things there too.
> Any major sites running python?
Instagram is probably the biggest headliner these days, but there's stacks of others.
If you want a measure of plain request/response I’d use the JSON benchmarks as the baseline.
Fair enough, sure.
> lack of backpressure
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.
https://github.com/MagicStack/asyncpg
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.
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?
And then going back to building their products. On GitHub.
Oh, wait.
I'm happy with the choice.
There are also "autogenerated API clients", where the API code is templated, based on the API schema.
(I think the swagger-js client also falls into the "dynamic" category, tho most other language implementations based on swagger fall into the templated "autogenerated" category.)
And, yup, working towards bring Core API up to feature parity with Swagger, so that you can fully interoperate with everything that the Swagger ecosystem already provides.
I'm not giving a free pass simply because it's open source. Rather it's an informed decision that I'm able to make because they're completely transparent about what limited metrics they aggregate.
Personally, I'm in broadly favour of them collecting basic metrics, their motivations for doing so, and the approach they've taken.
* That Phone in your pocket? "No problem"
* The browser you're using right now? "This is fine"
* Your internet-enabled TV? "All good"
* Open source project collecting usage metrics? "Woah, hold on there buddy"
Get some perspective.
They're completely transparent about which very limited usage metrics they use. You can inspect exactly which metrics are sent. And you can turn off these metrics if you want.
You're not paying anything for the product, and the analytics aren't being used to target you as a consumer, or to pitch advertising at you.
Simply by reading this page on hacker news you've sent more information to a third party than you would using brew.
It's just that kind of funding is a little more complicated to justify, as the outcomes are less well-defined.
I'm sure there'll be existing projects will be able to roll with the terms, and use the money in a way that both builds new functionality, while also refining the existing project.
Is the fund applicable to financing ongoing triage for projects? Nope.
Is €30k worth of funding for 40 kicking off individual projects valuable and worthwhile? Hell, yes.
Might the scope of an endeavor like this evolve in coming years, as they demonstrate success? Sure.
Government backed funding for OSS projects is a really smart and efficient use of public money when it comes to investing in digital infrastructure. It doesn't need to be perfect on launch, and it's far easier to pitch and justify the value of seed money like this, than it is to make (just as valuable, but more subtle) wider case for ongoing funding.
Furthermore I'm sure there's plenty of projects that could pitch proposals for new features that they want to build, while building in the cost of ongoing triage during those 6 months. (Ie. Make sure that the amount of work your proposing is viable on the assumption that you'll also have ongoing triage work to keep on top of at the same time.)
Let's celebrate the OSS funding achievements as they come, rather than knocking them.