I've made a pair of PR's, one for Django master and one for the 1.11
branch. On master, which is Python 3+, getattr_static is used 👍.

https://github.com/django/django/pull/8599
https://github.com/django/django/pull/8601

On 3 June 2017 at 01:02, Carl Meyer <c...@oddbird.net> wrote:

> Hi Zack,
>
> On 06/02/2017 02:02 PM, Zack Voase wrote:
> > Hi all,
> >
> > I'm encountering exceptions in a number of popular third-party Django
> > libraries when upgrading from 1.8 to 1.11. The code path is typically
> > `MyModel.objects.get_or_create(...)`, which causes
> > `model._meta._property_names` to be checked (to make sure we're not
> > querying/setting a property). The problem is, `_property_names` is
> > implemented as follows:
> >
> > |
> > # in django/db/models/options.py:
> > def_property_names(self):
> >     returnfrozenset({
> >        attr forattr in
> >        dir(self.model)ifisinstance(getattr(self.model,attr),property)
> >     })
> > |
> >
> > The problem is when a custom field installs a field descriptor on the
> > model class (during `contribute_to_class()`), with a `__get__()` method
> > like this:
> >
> > |
> > classSomeFieldDescriptor(object):
> >     # ...
> >     def__get__(self,instance,type=None):
> >         ifinstance isNone:
> >             raiseAttributeError("Can only be accessed via an instance.")
> >         # ...
> > |
>
> I can see two things here that could be done better, one on Django side
> and one on third-party app side.
>
> 1) I've never seen a good reason for a descriptor to raise an
> AttributeError like that. Typically `return self` is a much more useful
> option for the "access on the class" scenario, if the descriptor can't
> provide useful behavior in that case, as it allows introspecting the
> class and finding the descriptor object.
>
> 2) On the Django side, I think we should switch to using
> `inspect.getattr_static`, to avoid any possibility of triggering
> side-effecty descriptor code of any kind. AttributeError is only the
> most visible problem here; there could be much subtler problems (e.g.
> performance issues) caused by e.g. accessing a descriptor that does a
> database query or something.
>
> Carl
>
> --
> 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/fbd639ad-6a51-7657-f647-753cbc3b6b90%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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/CAMyDDM1Y2a3N0yz4fBNpG9qCKxAcci5QN2Muf2B2eKyN6ebxjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to