OK, here is some of the feedback from the Technical Board, aggregated
together:
* There were questions around contextvars and if they might supplant the
need for a threading.local override - I clarified why this doesn't work in
the DEP.
* Several board members queried around how we might
On Sun, Jul 21, 2019 at 1:11 PM Ehigie Aito wrote:
> Django 3.0?
>
Django follows time-based releases; what's in Django 3.0 will depend on
when we can get it landed. At the moment I am optimistic something will
make it in, but I make no promises!
Andrew
--
You received this message because
Django 3.0?
On Sun, Jul 21, 2019 at 9:02 PM Andrew Godwin wrote:
> I'll ask permission and then summarise the points raised back out here!
>
> Andrew
>
> On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss
> wrote:
>
>> Congratulations, and great news!
>>
>> I hope the TB will consider sharing
I'll ask permission and then summarise the points raised back out here!
Andrew
On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss
wrote:
> Congratulations, and great news!
>
> I hope the TB will consider sharing details and/or a summary of the "long
> and involved vote"; I'll bet there's a
Congratulations, and great news!
I hope the TB will consider sharing details and/or a summary of the "long
and involved vote"; I'll bet there's a bunch the broader community could
learn from the specifics.
Jacob
On Sun, Jul 21, 2019 at 3:54 PM Andrew Godwin wrote:
> Hi everyone,
>
> After a
Hi everyone,
After a long and involved vote, I can announce that the Technical Board has
voted in favour of DEP 0009 (Async Django), and so the DEP has been moved
to the "accepted" state.
As some may have seen, I've started work on adding async support to views (
On Sat, Jun 8, 2019 at 3:14 AM Pascal Chambon
wrote:
> Hello,
>
> There is something a little scary for me, in changing all the core of
> Django to async, when this really helps only, imho, a tiny fraction of
> users : websocket/long polling services, and reddit-like sites with
> thousands+ hits
Hello,
There is something a little scary for me, in changing all the core of
Django to async, when this really helps only, imho, a tiny fraction of
users : websocket/long polling services, and reddit-like sites with
thousands+ hits per second. For most webpages and webservices, async
artillery
On Fri, Jun 7, 2019 at 9:19 AM John Obelenus wrote:
> I wonder about the end-result payoff of this approach. In general,
> Django/Python code is not going to be I/O bound, which is where
> asynchronous approaches are going to get the bang for your buck. Even when
> it comes to DB access—the DB
I wonder about the end-result payoff of this approach. In general,
Django/Python code is not going to be I/O bound, which is where
asynchronous approaches are going to get the bang for your buck. Even when
it comes to DB access—the DB is a lot faster than the python and django
code running
On Thu, Jun 6, 2019 at 3:20 PM Pkl wrote:
> Hello,
>
> I'm a little late to the party, thanks for the big overview on this
> complex matter.
>
> There are lots of thinks I still don't understand though, for example
> regarding "what it unlocks". What asyncio structures would allow to run
>
Hello,
I'm a little late to the party, thanks for the big overview on this complex
matter.
There are lots of thinks I still don't understand though, for example
regarding "what it unlocks". What asyncio structures would allow to run
several DB queries concurrently safely and easily, that
Just a heads up that feedback on this draft DEP has slowed down, and so I
have merged it into the deps repository.
This is an invitation for any additional feedback before I take the DEP to
the Technical Board to get their opinion in a week or two. In the meantime,
I am going to start work on
On Mon, May 13, 2019 at 4:31 AM Tobias Kunze wrote:
> Hi Andrew (and everybody following the discussion, of course),
>
> First off, thank you for your work here. DEP9 is an excellent technical
> document, and it was as easy and pleasant to read as a document of this
> scope and depth can be.
>
>
Hi Andrew (and everybody following the discussion, of course),
First off, thank you for your work here. DEP9 is an excellent technical
document, and it was as easy and pleasant to read as a document of this
scope and depth can be.
Especially the Motivation section was very insightful – it might
On Fri, May 10, 2019 at 3:51 AM Asif Saif Uddin wrote:
> I have a separate question. Is it possible to get the django 3.0 asgi
> things into a different package to use with django 2.2?
>
> Thanks for the great work.
>
>
Unfortunately not - this is covered a little in the section in the DEP that
I have a separate question. Is it possible to get the django 3.0 asgi
things into a different package to use with django 2.2?
Thanks for the great work.
On Friday, May 10, 2019 at 3:42:08 PM UTC+6, Patryk Zawadzki wrote:
>
> We've always considered that implicit queries on attribute access were
>
> We've always considered that implicit queries on attribute access were an
> intractable problem. I said it on stage an DjangoCon US 2013. I'm now
> wondering if I was wrong all along! In an async ORM context, every time we
> traverse a relation, we could create a Future that would execute
On Thu, May 9, 2019 at 2:44 PM KimSia Sim wrote:
> I have a question that strays slightly away from the main topic. I have
> looked at Tom's repos. Is it encode/databases
> https://github.com/encode/databases that you're referring to?
>
> Or do you mean Tom's working on an async ORM that works
On Thu, May 9, 2019 at 2:15 PM Patryk Zawadzki wrote:
> I don't think it makes a significant difference from a readability
>> perspective in this example. It does have some advantages, though:
>>
>> - It could be easier to implement a sync version based on the async one,
>> or vice-versa, if
>
> I don't think it makes a significant difference from a readability
> perspective in this example. It does have some advantages, though:
>
> - It could be easier to implement a sync version based on the async one,
> or vice-versa, if each one has its own class. It will probably be more DRY.
> -
Hi Andrew,
I joined this group and chat because I saw the twitter post you made about
this DEP. I find that interesting.
On Friday, May 10, 2019 at 3:49:30 AM UTC+8, Andrew Godwin wrote:
>
> Tom Christie, for example, has already started work on an asynchronous
> ORM. Some of Django's
>
> I don't think it makes a significant difference from a readability
> perspective in this example. It does have some advantages, though:
>
> - It could be easier to implement a sync version based on the async one,
> or vice-versa, if each one has its own class. It will probably be more DRY.
W dniu czwartek, 9 maja 2019 22:47:48 UTC+2 użytkownik J. Pic napisał:
>
> I'm a bit confused here, what benefit are you getting from async emails if
> you're already retrying emails in the background in production ?
>
Anything that uses I/O should be async to unblock the worker to process
Nevermind my question you will get a lot more out of the workers, that
Django 3.0 is going to be really blazing fast like channels that calls for
a celebration xD
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
> On 9 May 2019, at 22:06, Andrew Godwin wrote:
>
> Jannis suggested what I think might be a nicer approach on Twitter, which is
> to add an async "proxy object" to access methods with, e.g.:
>
> cache.get("foo")
> cache.async.get("foo")
>
> This is still explicit but looks less ugly, and
Hi Andrew,
On Thu, May 9, 2019 at 10:04 PM Andrew Godwin wrote:
>
> If you want guaranteed email delivery, that's a task for something like
> Celery or a third-party API; any method of sending emails in the background
> in the same process, be it threads or async coroutines, is going to be
>
>
> I am also not a fan of the approach, but I did err towards being explicit.
> Jannis suggested what I think might be a nicer approach on Twitter, which
> is to add an async "proxy object" to access methods with, e.g.:
>
> cache.get("foo")
> cache.async.get("foo")
>
> This is still explicit
On Thu, May 9, 2019 at 1:04 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello Andrew,
>
> Thanks for your work putting together this plan. Within our constraints,
> it's a good plan.
>
> Regarding templating, I would say it isn't a priority because a developer
> who knows
> Slightly off-topic but once we have an async ORM, making it synchronous
is not impossible (I believe either Channels or Daphne already have shims
that use a worker thread to spin the event loop until a future is
fulfilled).
This is in fact the proposed way to make the ORM work with both sync
Hello Andrew,
Thanks for your work putting together this plan. Within our constraints, it's a
good plan.
Regarding templating, I would say it isn't a priority because a developer who
knows how to parallelize I/O bound operations will prefer (or at least accept)
to perform these operations in
>
> That said, I also think it's important to allow the ORM to support both
> modes in the long term. I truly believe the best way to be able to write
> async code is to _have the choice to write it_, rather than being made to
> all the time; if we make people use a separate, async ORM, then
In one project I really enjoyed using channels just as a background worker
instead of celery, and the DEP does not talk much in the Email section: use
the async variant, can be tackled separately, low priority.
For now the ORM works, but if sending an email fails (ie. SMTP down) it
will raise an
I would agree with both of you - I think the most important thing is to get
the view layer async-capable, as that then lets sites use any manner of
asynchronous libraries that already exist to get experiments and unique
things going. Tom Christie, for example, has already started work on an
>
> I'm not sure but for me the "What is Django" section answers the question.
> For me Django is full of philosophy that seeds a great ecosystem of apps of
> all sorts with a growing user base nonetheless, and a bunch of brilliant
> hackers to look up to and inspire for more. Of course if
Oops too fast, if it's possible to split the DEP and delay the ORM as
advised by Patrick it could make it a lot easier to distribute the work, I
don't know really sry. Have a great day !
--
You received this message because you are subscribed to the Google Groups
"Django developers
Hi Patryk,
I'm not sure but for me the "What is Django" section answers the question.
For me Django is full of philosophy that seeds a great ecosystem of apps of
all sorts with a growing user base nonetheless, and a bunch of brilliant
hackers to look up to and inspire for more. Of course if
Hey Andrew,
Great work on the DEP, the task at hand is humongous.
Do you think it's worth it to try and make the ORM async? It contains tons
of magic that is inherently incompatible with explicit I/O that is required
for async/await to work, things like silently fetching relations on first
38 matches
Mail list logo
