I somewhat second what Adrian wrote:
- try-except handling seems to be the most idiomatic way to me
- a flag altering API behavior as .get(..., raises=False) might come
handy, and to avoid naming collisions in arguments this could also be
shaped as a separate get_or_none() method - but: I somewhat doubt its
usefulness just cluttering the API further for low benefit, also nothing
stops you from wrapping the exception way into such a query helper (or a
more advanced resemblance of .get as Uri does). In fact the exception
will create a tiny runtime overhead on interpreter side, but thats
really tiny compared to the db roundtrip (thus against the whole .get +
helper runtime).
Imho a chaining .checked() method on the manager/queryset is not a good
idea, as it might create more API ambiguity - What should .checked() do,
if it is not followed by .get()?
Cheers, jerch
--
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/2dc8265b-44c2-6112-084f-07cea4589834%40netzkolchose.de.
