#30427: Descriptors not accessible for inherited models.
-------------------------------------+-------------------------------------
     Reporter:  Jarek Glowacki       |                    Owner:  nobody
         Type:  Bug                  |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  inherited            |             Triage Stage:  Accepted
  descriptor deferred                |
    Has patch:  1                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Jarek Glowacki):

 * has_patch:  0 => 1


Comment:

 Issue was introduced here:
 https://github.com/django/django/pull/6491/files#diff-
 bf776a3b8e5dbfac2432015825ef8afeR699

 Fixing it will not be backwards compatible (obviously), but we can remain
 true to the in-code comment and protect class methods from being
 overridden.
 That check currently also lets other falseys slip through. ie if my above
 example had been setting `A = 0` instead of `A = 1`, the deferred
 attribute would've come into effect properly. Such behaviour feels very
 wishy-washy (it should've been comparing to `None` at least), so I feel it
 would be safe to introduce a change to this into the next release (or
 perhaps even as a bugfix into this one), with a oneline statement in the
 release notes to warn anyone who might for some strange reason be relying
 on this behaviour..

 I've submitted a PR. Works, but it leaves a question around what we should
 be doing about `@attribute`-decorated methods. These slip under the radar
 of the `callable` check. So either we need to check for them separately,
 or we should rethink whether there's a point to preventing overriding of
 class methods in the first place.

 Thoughts? Does anyone know why we were protecting classmethods in the
 first place, seems like we should be just letting the mro do its job and
 always override, no matter what it is we're overriding.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/30427#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.eb25f2238169f592a3a8154d531ac729%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to