904baf11

Please do not deny my right to free speech.

> People that are particularly entrepreneur-minded often don't make for great employees (I'm in that group).

No boss, I can't meet that deadline, I'm too smart.

I guess UK citizens settled in other countries can pretend they're Irish?

Sure you do; don't live in the place with the tax.

This would not actually stop anything, just create a bunch of lawsuits.

It's what you would get if you trained a prediction model exclusively on HN threads relating to nutrition.

I use #python as an absolute last resort.

> Even on that aspect, I'd be interested in knowing how you'd achieve bidirectional communication async generators. How would the ASGI server call into the application and handle messages coming both ways? Surely, it can't just `async for message in agen: ...`, as that would only replicate the `send()` ASGI callback — what about `receive()`?

Yield is two-way. ``result = await agen.asend(next_message)` ` et al.

> Having worked and developed with it extensively for over a year now, ASGI is one of the most elegant and well-designed interfaces I've seen.

Having worked with Python async for 3 years, anything that asyncio touches is completely poisoned. ASGI is another in the line of terribleness of the modern async ecosystem.

> Besides, how would middleware look?

A second async generator.

> And you probably wouldn't be able to support all the possible syntactical implementations allowed by the notion of a Python callable

Require an async generator. Done!

> Also, I wholeheartedly congratulate the Django team for pushing the standard out there and driving the Python async web ecosystem forward. You rock!

Much like asyncio, something isn't good just because it's being pushed.

Calling the receive async function gets you a dictionary with a string type key, which defines the layout of the dictionary. It's not nice.

> while keeping it somewhat WSGI-compatible

There's the problem. WSGI is fundamentally flawed too - it could also be using generators for a two-way communication channel instead of stringly typed callbacks.

In a world where Python has optional static type hints, it would be nice to have concrete objects passed too.

It's convuluted, it's not structured concurrency (https://vorpus.org/blog/notes-on-structured-concurrency-or-g...), fundamentally despite being async/await a lot of networking code is based on callbacks anyway (see: asyncio.Protocol), and I've had a lot of trouble debugging code that spawn tasks because asyncio code has zero obligation to care about any of the tasks it spawns.

> ASGI support

> Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application.

Bleh. ASGI is probably the worst implementation I can think of for a common async interface. Stringly-typed callbacks? async generators exist for a good reason. It's also very asyncio-centric, and asyncio is Not Good.

> Your body will heal itself with rest.

Love too keep my arm permenantly lowered because ibuprofen is evil and rest is good

I've lost a small amount of weight whilst still entirely eating bread this year. The only thing food groups have to do with it is how filling everything is

> it’s hard not to worry about the similarities.

I don't find it hard to not worry about it at all.