On Friday, October 15, 2021 at 12:39:52 PM UTC-5 pyt...@ian.feete.org wrote:
> You set out a good case, it's much easier to understand the "why" here than in the original ticket. Yes. It was hard to compress the matter down small enough to reasonably fit in a Trac entry, so skipped the vast majority of the rationale. Sorry that it took that much writing to make the case, but had to set the groundwork first. On later consideration, the two most compelling points seem to be: * Internal machinations of Django shouldn't change object relationships that the application-level code has set * save() shouldn't have different effects (-sometimes- uncaching the reference) if the parent object is inserted versus updated > I'd avoid the extra optimisation of accessing __dict__ directly though - if __set__ gains extra functionality, I'd prefer not to accidentally miss it here. Agreed! Not being sure just how widely spread accessing the underlying __dict__ is throughout the code, I wasn't sure which way to go. Although it may be a -measurable- improvement in performance, it's miniscule. baj -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/14d1a470-4026-4f06-bfde-265bc7d8a667n%40googlegroups.com.
