Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Simon Charette ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"75924cfa6dca95aa1f02e38802df285271dc7c14"]:
 {{{
 #!CommitTicketReference repository=""
 revision="75924cfa6dca95aa1f02e38802df285271dc7c14"
 Fixed #21563 -- Single related object descriptors should work with
 `hasattr`.

 Thanks to Aymeric Augustin for the review and Trac alias monkut for the
 report.
 }}}

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.cbf1689555dac73dab6522f3deaf9bf7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by charettes):

 * cc: charettes (added)
 * has_patch:  0 => 1
 * version:  1.6 => master
 * stage:  Accepted => Ready for checkin


Comment:

 Opened a [https://github.com/django/django/pull/2056 PR] with the changes,
 I'll ship it if no objections are raised in the next days.

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.45a68fcaac3b7580716e11e9f9678faa%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 Replying to [comment:3 aaugustin]:

 > It could be preferrable to define `RelatedObjectDoesNotExist` similarly
 for the forwards and backwards relations. Is there a downside to using a
 cached property for both? I value consistency a lot in this area of the
 code base, for reasons that must be obvious to you by now ;-) Once you've
 considered this question, ship it!

 No objection to use a `cached_property` in both cases.

 I kept the one created at initialization time since I felt like the
 `cached_property` approach was kind of ''hackish'', hence the
 `ReverseSingleRelatedObjectDescriptor`
 
[https://github.com/charettes/django/commit/6a83d41c38e01e0aecbd1e90ca4aa36f10b0925d
 #diff-3010fc5a498b7171c342520f34507968R266 comment].

 I'll add a comment to explain
 `SingleRelatedObjectDescriptor.RelatedObjectDoesNotExist` is also a
 `cached_property` for the sake of consistency.

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.1631c07bc7fceffa9a596a8a3d610aa5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 The patch looks good to me.

 It adds tests for both forwards and backwards relations.

 I don't see a reason to make this new exception a public API. It's just
 making `hasattr` behave as expected. Therefore, no documentation is needed
 at this time.

 It could be preferrable to define `RelatedObjectDoesNotExist` similarly
 for the forwards and backwards relations. Is there a downside to using a
 cached property for both? I value consistency a lot in this area of the
 code base, for reasons that must be obvious to you by now ;-) Once you've
 considered this question, ship it!

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.871584418c0563e3bb506efd06185055%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 Replying to [comment:1 aaugustin]:
 > Could we raise a `RelatedObjectDoesNotExist` exception inheriting both
 from `DoesNotExist` (for backwards compatibility) and `AttributeError` (to
 change the behavior according to your suggestion)?

 [https://github.com/charettes/django/compare/ticket-21563-hasattr-related-
 manager Gave it a try] and it seems worth considering. The full test suite
 passes on Python2.7 SQLite3.

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ee696f773d63660746570d5c67e74783%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
-+-
 Reporter:  monkut   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 This is a bit tricky.
 [http://docs.python.org/3/library/functions.html#hasattr Python's
 documentation for hasattr] notes that it's "implemented by calling
 `getattr(object, name)` and seeing whether it raises an `AttributeError`
 or not". However, when no related object exists, Django raises
 `DoesNotExist`, not `AttributeError`.

 Could we raise a `RelatedObjectDoesNotExist` exception inheriting both
 from `DoesNotExist` (for backwards compatibility) and `AttributeError` (to
 change the behavior according to your suggestion)?

 I'm not entirely sure it's a good idea, but it's worth considering.

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.27fcbc9dbafb88bf7b6cb270114df6b1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when False

[Django]

#21563: calling hasattr(model_instance, fieldname) raises DoesNotExist when 
False
---+
 Reporter:  monkut |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Using python 3.3 and django 1.6.

 I've got a model (created from an AbstractBaseClass) and creating an
 instance of the model from some JSON, via serializers.deserialize(), then
 checking if the resulting parsed JSON model has the fields I'm expecting.

 (thinking about it now, this seems like the wrong thing to do, since it
 may be expected that the resulting Model instance has the field, but takes
 the default value? but anyway...)

 When I check to see if the parsed instance.object has the given attribute,
 via hasattr(), it's raising DoesNotExist, instead of returning the
 expected False.

 Again, maybe it's ok that it doesn't return False... but I don't think
 hasattr() should raise an exception.



 {{{

 from django.contrib.auth.models import User

 class BaseTask(models.Model):
 assigned_to = models.ForiegnKey(User)

 class Meta:
 abstract = True

 class Task(BaseTask):
 pass
 }}}



 {{{
 Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64
 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from myproject.myapp.models import Task
 >>> from django.contrib.auth.models import User
 >>> t = Task()
 >>> hasattr(t, "assigned_to")
 Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Python33\lib\site-packages\django\db\models\fields\related.py",
 line 314, in __get__
 "%s has no %s." % (self.field.model.__name__, self.field.name))
 django.contrib.auth.models.DoesNotExist: Task has no assigned_to.
 >>> u = User.objects.get(pk=1)
 >>>
 >>> t.assigned_to = u
 >>> hasattr(t, "assigned_to")
 True
 >>>
 }}}

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.834c376b1f4b7805fcca414eae394fe4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.