I agree with what James eloquently said, the issue is more complicated it appears.
Simon Le mardi 15 octobre 2019 05:59:27 UTC-4, James Bennett a écrit : > > This request is a bit more complicated than I think people > realize. There's no practical way I can see to have the __repr__() of > a QuerySet supply information sufficient to reconstruct it, at least > not in a manner recognizable to most users of the ORM (there's no > internal record of which query methods were called, or with which > arguments -- only the manipulations of the nodes of the underlying > Query object). > > And even if we decided to go to the trouble of having QuerySet store a > record of query method calls, it's likely to be a considerable amount > of trouble, since arguments to query methods may be objects that are > difficult or impossible to safely store (such as iterators which would > be consumed in creating a string representation). > > So having QuerySet.__repr__() produce the sort of "information to > reconstruct the object" typical of the __repr__() of Python's builtins > is not going to work. > > Which leaves the question of what to put in the __repr__(), if it's > not going to be a way to reconstruct the QuerySet and it's not going > to be the results of the query. We would also need to ensure QuerySet > implements __str__() in a way that *does* provide the visual debugging > aid of showing the results, since currently it doesn't, and relies on > Python falling back to __repr__() to get the string representation. > > And... I don't have a good answer to this. Anything that isn't either > the method chain to reconstruct the query, or the results of the > query, is not going to be a sufficient debugging aid. > > Which brings us back around to the current behavior; it seems to me > that this is the most useful thing we can do. It's already documented > that a string representation of a QuerySet shows the results, which > requires evaluating it and performing the query. There are some small > optimizations we could do -- such as checking for a populated result > cache and using it, rather than re-performing the query as __repr__() > currently does -- and we could be more explicit about the fact that > performing the query is a requirement for generating a string > representation, but I think that's about the best we can do for this > issue. > -- 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/f0e3d894-1f00-45b0-8615-ffd211f51bcd%40googlegroups.com.
