Luke, thank you for your explanations. If I answer once more, then I do it in the hope that our discussion may help to improve Django.
On 8.02.2010 0:38, Luke Plant wrote: > It is easy to fix - a few lines in > ReverseSingleRelatedObjectDescriptor - because the behaviour there is > not accidental, but quite deliberate. I admit that I am surprised to hear this. > The behaviour is only odd from > one angle, and it is not very strange, because ForeignKey fields *are* > a fundamentally different type of field. The corresponding 'normal' > field is the '_id' field - this is a dumb value. Sorry, but I still don't understand the angle from which this behaviour is *not* odd. And the corresponding '_id' field is added 'behind the scenes', so using it should be avoided as much as possible. > I think you are missing the fact that this behaviour occurs *whenever* > the FK val is an invalid value, not just with creating new instances. No, I considered this. I wrote already the two possible causes of exceptions that I can imagine. > You are therefore asking either for special treatment of instances > that are not saved to the database, or for it to be broken in general. That's no special treatment. I'm asking to have the same behaviour for nullable and non-nullable ForeignKey fields (until save()). Having 'None' in a non-nullable field is a normal case of an instance containing invalid data. Imagine an application that runs a complex series of handlers on an instance that decide how to set some fields depending of the (valid or invalid) values contained in some other fields. You cannot ask user code to not even look at invalid data. I'm not allergic to exceptions, but raising an exception when I ask for the content of a field is not appropriate behaviour. > Consider this code: > >>>> o = SomeModel.objects.get(id=1) >>>> o.fk_field_id = None >>>> print o.fk_field > > Are you are proposing that the above should print 'None' even when > fk_field is non-nullable, rather than a DoesNotExist? Yes. Though I'd say "o.fk_field = None" instead of "o.fk_field_id = None", because the '_id' field should remain behind the scenes. Anyway both should have the same effect. > 'o.fk_field' is > a shortcut for a DB lookup of 'o.fk_field_id', and clearly the result > of that lookup is *not* None/NULL. The query returns no results, and, > just like every other case when a query returns no results and we > expect at least one, you get a DoesNotExist exception. (In this case > we skip doing the actual database query as an optimisation, but the > same logic applies). 'o.fk_field' is an attribute of a Model instance, and Django should never refuse to show what it contains, even if that value is illegal. Okay, it's obvious that Luke's and Luc's understandings of that problem are quite different. We both explained our points of views. The next step would be to hear other people's opinions. I personally won't insist further, especially since Luke knows Django better than me. May I suggest again to mark this ticket to something different than "duplicate of an invalid ticket"? Luc -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
