> Django is now aware of asynchronous event loops and will block you calling code marked as “async unsafe” - such as ORM operations - from an asynchronous context.
So DB calls aren't async?
Django 3
91–100 of 196 posts
Re: Django 3
#92Was 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-...
I've replied to the post on the forum, but if this is the default way Jupyter runs then we're going to have to figure something out longer-term. Calling the Django ORM from an async thread just isn't safe...
Re: Django 3
#93I 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?
id like to chime in with positive experiences with FastApi and starlette
Re: Django 3
#94I 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?
I've been messing around with FastAPI as well and it really is such a pleasure to use. ️ Its documentation is what really makes it a stellar project for me.
Re: Django 3
#95Earlier quoted context omitted.
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()
It didn't, async await is just syntactic sugar on top of coroutines/futures. You can define an sync function and get a coroutine back if you call it without await. It's still kind of a mess though because you have two universes that are not really compatible, forcing you to rewrite everything that touches IO. For django that probably means a rewrite of the ORM, caching and middlewares.
JS async/await is also just syntactic sugar on top of Promises (which are basically just futures with the ability to write as well).
Re: Django 3
#96Earlier quoted context omitted.
I'd love to hear your suggestions for changes we could make while keeping it somewhat WSGI-compatible. It took a few years to refine it to where it is now, so it's not like we just threw something at the wall.
> 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.
Can you expand on the stringly typed callbacks? Where are they required? Are you referring to string keys in a callback dictionary, in which case stringly-typed seems a bit of an odd choice of words.
Re: Django 3
#97Was 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-...
I've replied to the post on the forum, but if this is the default way Jupyter runs then we're going to have to figure something out longer-term. Calling the Django ORM from an async thread just isn't safe...
Thanks for the reply and all of the great work.
Using django in a notebook is definitely not a typical use case so I wouldn't worry about it too much.
Ideally the ORM would be a standalone package that could be used outside of the web server context. (I know sqlalchemy is an option but then you lose all of the benefits of django)
Re: Django 3
#98Earlier quoted context omitted.
> 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.
Can you expand on the stringly typed callbacks? Where are they required? Are you referring to string keys in a callback dictionary, in which case stringly-typed seems a bit of an odd choice of words.
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.
Re: Django 3
#99The last time I used django was for one piece of a capstone related project back in college, and for what I was doing, it was dead simple (to get up and running, that is).
I’ve seen python used extensively for data science work, but I’m not sure how well dynamic typing works (in terms of support ability/maintenance) in a larger code base, especially as some trivial knowledge gets lost and newer folks are introduced to an older code base. Do you just set break points to trace? I digress, but open to hearing folks thoughts.
Re: Django 3
#100I 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?
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?