> > 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. > - It could also be a bit more usable by developers, especially in IDEs >
Right. It could also be a sub-class on the class in question to make the implementation easier - e.g. "core.cache.cache.sync" is a literal passthrough, and "core.cache.cache.async" is the async wrapper implementation. > > Also it could provide an alternative solution for the async attribute > access problem: `model_instance.async.related_field` could be a Future > that, when awaited, resolves to the related field. So you could `await > model_instance.async.related_field` instead of having to `select_related`. > To be honest I didn't investigate all the consequences of this idea. It > seemed worth mentioning, though, even if it turns out to be impractical :-) > I think this might be feasible? I'd want to probably push it to have its own research and proposal, probably, but it might be a nice way out of the initial thing of requiring select_related. I just don't know enough about how that might cascade down the ORM internals to judge it at this point! Andrew -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1upEsCpnL-81guSw_vKLn%3DWmfM3pamuFY%2BSZWLMerNC0yA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
