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
Hello everyone,
While the ASGI patch (https://github.com/django/django/pull/11209) is maybe
the first small step in a long road to async, it's the only real one we
could do without a DEP as it purely pulls on existing specs and bugs.
To that end, I have drafted a DEP (provisionally #0009),
Maybe you would want to install an app without having their urls injected
then you're going to need to do things like
INSTALLED_APPS = [
someapp.AppConfig(urls=False)
]
Of course this is going to make complicate the settings system, but why not
hook a callback in AppConfig that is executed
>
> It looks like app maintainers really ought to give django-gdaps a
> shot. Perhaps Christian, another way would be to contribute gdap
> support to the apps you like to use in the ecosystem. Then their
> maintainers could benefit from it if they install gdaps and so it can
> propagate in the
In the example Config.ready() calls for a dict update() which will
probably work for a while, before changing the update() call in the example
with more elaborated code.
System checks shoud catch cases where configuration is invalid at all.
Not sure how much you can pull from entry points, if you
ERRATA in the code above, a mistake I make really often, instead of:
DebugToolbarMiddleware = debug_toolbar.middleware.DebugToolbarMiddleware
Should be:
DebugToolbarMiddleware = debug_toolbar.middleware:DebugToolbarMiddleware
In one python module I rely on this (cli2), I ended just making so
25 matches
Mail list logo
