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
-~----------~----~----~----~------~----~------~--~---
