Well from my own habits to use .get() only for unique filtering (>80% on
pks only) I also see some benefit of a .get_or_none() variant - it would
stop writing those exception handler wrappers over and over halfway
during project realization. A ready-to-go official way would reduce that
to a conditional expression from line one on.
> .get_or_none() probably should allow to query only pks and
> unique_together fields, so there will be no third state?
To begin with - thats the place I dont like .get() at all. The fact that
it might end up with multiple objects is a nuisance, but we cannot do
much about it for API compat reasons. Idea - if we want such a changed
behavior - maybe call it "unique_or_none()" to make the difference
clear? If its called .get_or_none() imho it is better to stick to .get()
behavior regarding multiple objects (still raising).
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/9e322498-0909-cf3d-08bc-f62cca789f23%40netzkolchose.de.
