On Wednesday, February 3, 2016 at 8:47:16 AM UTC+2, Anssi Kääriäinen wrote:
> For the update_fields change, I think we can do that completely > separately. The same goes for changing the way how deferred fields are > implemented. > I created a proof-of-concept pull request for improved deferred fields loading. See https://github.com/django/django/pull/6118. In short, it is faster and cleaner (no more dynamically created subclasses for deferred loading!) than the previous implementation, but we have a couple of backwards incompatibilities: 1) Model.__init__() will be called with value DEFERRED for those fields which are deferred. Previously those fields were not given to __init__() at all. 2) The class level attribute Model._deferred must be removed (we can't have class level attribute as we don't have dynamic classes any more) 3) A potential name clash for fields when one has a class method and field with clashing names. Of these the Model.__init__() case could be problematic for those users who have overridden __init__(). Before doing any further work on this we should decide if the Model.__init__() problem is bad enough to stop this cleanup, and if so, do anybody have any ideas of how to avoid the problem? - Anssi -- 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/ced9d758-4cfe-4012-b7fc-37aaf221a83e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
