101–110 of 196 posts
This looks neat. Does anyone have experience with using type hints and mypy with Django? Any gotchas?
Django (and DRF if you use it), uses too much reflection, which doesn't play nice with type annotations. The strategy that works for me is to annotate my application code, and keep using dynamic typing when interacting with the framework.
Earlier quoted context omitted.
But you have to be careful that all dependencies are up-to-date as well.
No to mention each new release have many incompatibility that you need to read the release note to find out
Do you have some examples? Are you sure you are not confused with dependencies?
The release notes mention less than ten deprecations related to django. Other stuff which is not supported anymore is mostly non supported database versions.
https://docs.djangoproject.com/en/3.0/releases/3.0/#backward...
Earlier quoted context omitted.
It's worth pointing out that the ASGI support in this release is very low level, and doesn't let you write async views or anything yet. We're still working on that.
Thanks for your work on this. If I am willing to hack a bit, is it possible? What is the main obstacle? Is it all middleware?
middleware is a part of it, then there's the ORM, caching and anything else that does IO.
> 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.
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.
Just wanted to address this:
> async generators exist for a good reason.
While the idea of using async generators might sound attractive at first, there's so much more to ASGI than exchanging messages in both directions.
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()`?
Besides, how would middleware look? Would it be as simple as wrapping `receive()` and `send()` into whichever other callable adds the functionality your middleware needs?
And you probably wouldn't be able to support all the possible syntactical implementations allowed by the notion of a Python callable: functions, classes, callable class instances.
So, yeah, I think ASGI is a beast.
Also, I wholeheartedly congratulate the Django team for pushing the standard out there and driving the Python async web ecosystem forward. You rock!
Was really excited to upgrade but the async safety check makes the ORM unusable in a Jupyter Notebook. https://stackoverflow.com/questions/59119396/how-to-use-djan... https://forum.djangoproject.com/t/is-there-a-way-to-disable-...
please tell me that python did not adopt the javascript async hell. async should be an optional keyword on the CALLER side, not an invisible trait of the function. go figure()
Alternatively, you can also use it with a plain Promise, which makes for a nice mutex. I've also used this for imitating async constructors, which is not currently possible.
> 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.
I don't often comment on HN, but I feel like this time I have to step up. 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. Just wanted to address this: > async generators exist for a good reason. While the idea of using async generators might sound attractive at first, there's so much more to ASGI than exchanging messages in b…
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.
I have been using FastAPI for the last two months (which also is an ASGI server and makes full use of annotations and type hints with mypy) and the experience has been incredible. ( https://fastapi.tiangolo.com/ ) If Django can now also support annotations and async code I dream of an scenario where apis can be built using this two elements. Does anybody know a good resource to learn/catch up with this release?
Earlier quoted context omitted.
I don't often comment on HN, but I feel like this time I have to step up. 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. Just wanted to address this: > async generators exist for a good reason. While the idea of using async generators might sound attractive at first, there's so much more to ASGI than exchanging messages in b…
> 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. > Havi…
It's still limited. To get a result you need to send something. Using it for something that's not strictly request-response can get complex.
> 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.
That's your own bias. I also used asyncio from the beginning and got a different opinion. The asyncio package that comes with python is low level and is meant for building frameworks. If you used aiohttp, asyncpg and other packages packages build on top of asyncio it's actually quite enjoyable.
This looks neat. Does anyone have experience with using type hints and mypy with Django? Any gotchas?
1. https://blog.zulip.org/2016/10/13/static-types-in-python-oh-...
Earlier quoted context omitted.
But you have to be careful that all dependencies are up-to-date as well.
No to mention each new release have many incompatibility that you need to read the release note to find out