tomchristie

We don’t have any third party packages for that authentication style yet, but we do have an API for supporting custom auth flows... https://www.python-httpx.org/advanced/#customizing-authentic...

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.

Yo. Two points here.

* 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.

That's really lovely, thanks for sharing.

HTTP/3 is slated as roughly HTTP/2 over QUIC but with some differences as a result. https://tools.ietf.org/html/draft-ietf-quic-http-20#appendix...

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.

Good call, given that it's not enabled in modern browsers, and is unreliably supported in proxies and servers.

It's for the best that it becomes widely treated as a non-feature of HTTP/1.1.

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.

"Et nous sommes encor tout mêlés l’un à l’autre"

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’s okay-ish. You do need to be careful about what falsey values `x` might be tho, as it could introduce edge-case bugs.

Using `x = [] if x is None else x` is more precise.

For me this is a simple philosophical question.

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.

Hell yes - it's an incredibly productive language, and the Web frameworks for it (Flask & Django in particular) are really nicely mature.

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.

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.

Nope, they run a warm up stage.

It's threaded vs async/await

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.

Nope, but probably going to be working towards a library similar to that/werkzeug. Request & Response objects, plus some standard middleware.

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.

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.

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?

a meaningful number of developers are openly questioning the web platform.

And then going back to building their products. On GitHub.

Oh, wait.

I just had a quick scan over the licenses of other projects used for server side projects. Projects using BSD/MIT include Node, Go, Rails, Django, and Flask.

I'm happy with the choice.

One thing to clarify here. Swagger/OpenAPI use JSON Schema in order to describe parameters and response structures. The rest of the schema work will start to fall into place pretty quickly now that we've got the groundwork done. Swagger generation based on the annotations will be one of the features, but there'll be plenty more to get excited about too.

To be precise I'd call it a "dynamic API client". The codebase doesn't change, you read the schema and corresponding actions become available on the client.

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.

Your pathetic argument. You should be ashamed of yourself

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.

He might be a nice target if you want to raise a stink and litigate.

* 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.

I think it fits well if you expect most projects to be a single engineer working full-time. An equivalent of up to €60k/yr full-time is a pretty good salary by most folks standards, even if it's not quite up there with top-tier engineering levels. (I'd probably suggest the funding was getting poor value-for-money if it was)

Sure. I think a slightly wider remit would be perfectly reasonable too.

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.

I think that's a rather negative outlook.

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.

Then don't sweat it! :)