On Dec 5, 2:25 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > It only just works :P > > it's called Fit For Purpose. You've yet to demonstrate somewhere in > Django we need all these extra levers of which you speak.
The lazy __proxy__ class is full of magical bits, which I don't really get the point of. Maybe I'm just dumb, but I'm sure something much simpler could have been created if the sole purpose was just a lazy string/unicode. I was under the impression that django.utils could be helpful for general use where possible, too. Like I said, I've got these "extra levers" working with less code than we currently have anyway. An example of where it could be useful in Django. I've been working on a new version of the session messages ticket and was looking at making the "messages" context variable lazy - it seems silly how it currently wipes messages, even if you didn't check for them. So I thought "hey, django has some methods to handle laziness. Great!": cache = {} get_messages = memoize(get_messages, cache, 0) get_messages = lazy(get_messages, list) That'd be great, except that you can't iterate, check the length, or do pretty much anything with it because of how lazy currently works. > > Currently a lazy object isn't considered an instance of its > > resultclasses > > So you can't do: isinstance(my_lazy_string, str) > > Correctly so. It *isn't* a str instance yet. It's something that can > proxy for a string in many instances, but computing the string form has > side-effects sometimes and they haven't been effected yet. Guess so. If lazy output a transparent proxy, I don't see why code should have to know the difference (and if it did, it could still check isinstance(x, Promise)). Checking whether an instance is a string seems like a bad way of checking whether computation had occured, anyway. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---