Malcolm Tredinnick wrote: [...]
This seems like a reasonable idea, although I'm not sure if __repr__ is the right place for it or not (and that's something that doesn't interfere with the implementation anyway, so I'm not going to worry much).
In principle __repr__ should be the right place (according to how Python defines __repr__), but I understand there could be compatibility issues.
I would suggest/prefer holding off trying to get this perfect until the QuerySet rewrite is done (something I am doing). As part of that rewrite, QuerySets will contain a slightly more abstract version of the SQL being constructed -- the SQL string itself will be formed as part of the __str__ method. This removes a bunch of the hackery needed to join queries together and provides some manipulation possibilities we don't have now. The upshot of this for your work is that it will probably be easier to extract a serialised form of the query itself. I'm not sure how much easier/harder it will be to print it out as a Python statement like the above in all cases, but some form of serialisation that will be easy to dynamically reconstruct should be possible.
Waiting will probably be better as we (at least I :) won't have to create backwards compatible constructors to QuerySets serialized the old way, which could be non-trivial. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
