Re: lazy (in utils.functional) is broken
Ticket opened. http://code.djangoproject.com/ticket/6272 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
I think I was just bitten by this. The model fields defined in django.contrib.auth.models (and I assume other parts of django) use django.utils.translation.ugettext_lazy to specify the label (or another property from which the label is derired). The form field objects generated by form_for_* and ModelForm on these models return a django.utils.functional.__proxy__ object instead of a unicode object where ugettex_lazy is not used. I have a few helper template tags which are trying to concatenate FormField.label, specifically one named form_field which accepts a form field as it's argument and outputs the appropriate HTML, which is throwing an error for form_for_model and ModelForm forms for django.contrib.auth.models.User. As the documentation doesn't recommend or require the use of ugettext_lazy in it's examples and tutorials when defining models and forms, this inconsistent behaviour seems less than ideal. If django.utils.functional.__proxy__ could be changed to behave more like a string or unicode object, at least in these cases, wouldn't that be a good thing? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Dec 17, 6:52 pm, "Gary Wilson Jr." <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > 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. > > What ticket number is this btw? http://code.djangoproject.com/ticket/4604 PS: I didn't want to continue this debate on lazy() and didn't want it to hold up the ticket, so I just wrote a custom lazy object. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
SmileyChris wrote: > 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. What ticket number is this btw? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Tue, 2007-12-04 at 20:47 -0800, SmileyChris wrote: > 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, Any time somebody uses the word "magic" or its derivatives on this list, I assume they don't expect people to read any further, because the discussion has left the realms of computer science. There are concrete lines of code there. Each one follows logically from the previous one. Precisely no magic is used. [...] > I was under the impression that django.utils could be helpful for > general use where possible, too. No. We're not providing funcitonal utilities. We're providing a web framework. Yes, django.utils is a dumping ground for some things that are public and some things that aren't, which is unfortunate, but not really convenient to change now. By and large, though, it's not public code (the stuff that is public is documented). It's common code we use internally. [...] > > 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)). Which is what we do. > Checking whether an instance is a string seems like a bad way of > checking whether computation had occured, anyway. Guess it's fortunate we don't do that, then. The point is that if something has isinstance(x, str) == True it must be a string in all ways. What we have in a delayed translation is not a string. For example, one of the consequences of something being a string is that when you pass it around and use it in different places, it has the same value. This isn't true for a lazy translation. It's why we use duck-typing, rather than sub-classing in the implementation. A lazy translation should behave like a string for the particular pieces of the public interface that we need, but it doesn't have to be a string in those places and we aren't going to mislead people by giving it the wrong type. This would be true for anything using lazy(). Don't confuse type identity and subclassing with behavioural similarity. They're different things. If you've got simpler code that achieves the same thing, obviously open a ticket (I didn't reply to that earlier because it's a silly habit to ask permission to post a patch: either do or don't, there is no "try"). I can't predict whether it will be accepted because we haven't seen any code. I know why a lot of the current stuff is in lazy() and, as far as I know, there are on known bugs with it for what we need (and I'm pretty much always going to be in favour of keeping it only for Django's internal use -- people wanting it externally can write their own variant that meets *their* requirements, rather than ours). Also remember that lazy() isn't just used for translations in Django. Malcolm -- Depression is merely anger without enthusiasm. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
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
-~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Mon, 2007-12-03 at 16:02 -0800, SmileyChris wrote: > On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > > lazy() > > > > Of course it works. We're using it throughout Django for lazy > > translations. > > 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. > 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. Malcolm -- Plan to be spontaneous - tomorrow. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Dec 4, 4:39 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > lazy() is complex enough without adding things we don't need. I guess this is my point. It seems that lazy() has been made overly complex for little gain. > If there's a legitimate case where Django core needs this extra > functionality, I'd probably first try to work out how to avoid it and > only then add it. If I wrote a simpler version of lazy(), which had this new functionality while keeping existing behaviour, would it be considered? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Mon, 2007-12-03 at 00:03 -0800, SmileyChris wrote: > On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > What method? > > lazy() Of course it works. We're using it throughout Django for lazy translations. Keep in mind though that most of the stuff in django.utils is for Django's internal usage and lazy() is certainly fit for its purpose. I guess what your original post was trying to say is that it doesn't work for all return types because sometimes methods on the underlying type have to be replaced. However, we don't need that (lazy() is predominantly used for string types) and so I've avoided adding the extra code to work all that out. lazy() is complex enough without adding things we don't need. If there's a legitimate case where Django core needs this extra functionality, I'd probably first try to work out how to avoid it and only then add it. If you're trying to use it as a general external things... well, as the joke goes "Doctor it hurts when I do this...". Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Dec 3, 6:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > What method? lazy() Maybe I just don't get how it is supposed to work, but the setattr line seems wrong, at least for setting special method names. Also confusing is that the docstring says "Results are not memoized; the function is evaluated on every access." Then the comment just under that says "Afterwards, the result is delivered directly. So the result is memoized." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
On Sun, 2007-12-02 at 20:44 -0800, SmileyChris wrote: > I tried actually using lazy today for something and couldn't get it to > work. > It seems to me that the current implementation is basically broken. > > For example, I was trying to do lazy(my_function, list) > __proxy__.__init__ tries to setattr(self, k, [promise]), but that > won't actually work for any magic methods, because they need to be > class methods. > > After hacking around with it a bit and moving that code outside > __init__, I got it to work. > > Once it is working, it makes __repr__ work properly on lazy objects > too (which probably is the solution to that problem I was having with > some new tests returning 0x...>)! > > In fact, the only easy way to tell that it isn't actually that object > type is to test is_instance() > > Has anyone else actually tried using this method before? What method? Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
lazy (in utils.functional) is broken
I tried actually using lazy today for something and couldn't get it to work. It seems to me that the current implementation is basically broken. For example, I was trying to do lazy(my_function, list) __proxy__.__init__ tries to setattr(self, k, [promise]), but that won't actually work for any magic methods, because they need to be class methods. After hacking around with it a bit and moving that code outside __init__, I got it to work. Once it is working, it makes __repr__ work properly on lazy objects too (which probably is the solution to that problem I was having with some new tests returning )! In fact, the only easy way to tell that it isn't actually that object type is to test is_instance() Has anyone else actually tried using this method before? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
