[gis] lazy-geometries/planning
GIS people, There don't seem to be any plans around how the gis branch is getting to its goals. For instance, the lazy geometries patch in 4322 is way off track now we have support for ogr geometries. I'm happy to write code/docs/tests, but it helps if i can see a little way into the future about what other changes are planned to happen, and who is working on what. I'm happy to have an IRC discussion to nut out details if we can find a time that suits people, or you can get me on IM - skype:robert.coup, msn/yahoo:[EMAIL PROTECTED] Cheers, Rob :) --~--~-~--~~~---~--~~ 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: "Possesive" filter
Sorry, I'll file a ticket in trac in future, and I had no idea google groups would file the email as it did, I thought I was starting a new discussion. I'll keep it in mind in future :) Mike Malcolm Tredinnick wrote: > On Sun, 2007-06-17 at 20:08 +0100, Mike H wrote: > >> Hi all, >> >> I needed a nice way of saying "mike's friends" in a template when the >> currently logged in user was "mike", but "james' friends" when it was >> james. I realise this is a very English biased filter, but here's a >> patch to add it to defaultfilters in template. >> > > Please (a) start a new thread for a new topic rather than just replying > to an unrelated post and (b) post patches to Trac so that they don't get > lost and can be reviewed in due course. > > Thanks, > 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: "Possesive" filter
On Sun, 2007-06-17 at 20:08 +0100, Mike H wrote: > Hi all, > > I needed a nice way of saying "mike's friends" in a template when the > currently logged in user was "mike", but "james' friends" when it was > james. I realise this is a very English biased filter, but here's a > patch to add it to defaultfilters in template. Please (a) start a new thread for a new topic rather than just replying to an unrelated post and (b) post patches to Trac so that they don't get lost and can be reviewed in due course. Thanks, 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: International standard for date and time
On Sun, 2007-06-17 at 06:13 -0700, Jonas wrote: > On 17 jun, 09:03, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Sun, 2007-06-17 at 00:54 -0700, Tai Lee wrote: > > > +1 - it's a simple default settings change. django is used by an > > > international community, so the defaults should be a format that is > > > understood by everybody without any possibility of ambiguity. those > > > that prefer a different format (american, or abbreviated or full > > > length month names etc) can change their settings. > > > > The current settings already are unambiguous. > > The current settings already are unambiguous *only for north > americans*. I'm sorry, but this simply isn't true. - Current default DATE_FORMAT is "N j, Y" which, right this minute, produces "Jun. 18, 2007". - Current default DATETIME_FORMAT is 'N j, Y, P' which produces "Jun. 18, 2007, 8:52 a.m.". - Current default TIME_FORMAT is "P" which produces 8:52 a.m. - YEAR_MONTH_FORMAT and MONTH_DAY_FORMAT similarly use words for the month and four digit years. None of those are ambiguous. You might quibble (as I would) that using month abbreviations rather than thefull name there is a flaw, but it's not fatal and there is absolutely zero doubt about what month, date, year, hour, minute and half of the day is being referenced. No matter what your particular locale, providing you know the English month names. They are all also marked as translatable by Django, so people using other languages see localised, similarly unambiguous versions of those strings. > Django is a project used by an international community (and grown by > that community) and its configuration should be set to an > international format by default. "International format" can mean a lot of things, not all of them good. One very strong argument against using an ISO format (which is well-defined and is what the original ticket was about) is that it isn't a very human-friendly string. If your friends asks you what the date is, you don't say "2007-06-18", you say "June 18". The goal of a date format is to unambiguously describe the date and time in a way that is understood by the reader. That is the main justification given in the links you posted earlier, too, if you have a look. However, none of those links address the human-readable phase particularly clearly. We meet the unambiguous and clear in all locale requirements with our current setup. If a website says "today is 2007-06-18 08:52", it is designed for people who are very familiar with computers and willing to compensate for some odd constructs like that; it isn't written to be invisible. Barring any particularly strong arguments in favour of this change, I'm becoming more and more inclined to "wontfix" this, since changing it adds work for translators and it's already something that is entirely under the control of project installers in any case. Regards, 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: possible deficiency in newform BooleanField?
On Jun 18, 10:23 am, Mike H <[EMAIL PROTECTED]> wrote: > Perhaps the example in the > docs needs updating to show required=False in the cc_myself field? Perhaps you should make a ticket. /me cracks the ticket manager whip. ;) --~--~-~--~~~---~--~~ 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: possible deficiency in newform BooleanField?
Thanks, didn't occur to me to use that :) Perhaps the example in the
docs needs updating to show required=False in the cc_myself field? Would
make a bit more sense as that form actually forces you to cc yourself ;)
Cheers,
Mike
SmileyChris wrote:
> On Jun 18, 8:44 am, Mike H <[EMAIL PROTECTED]> wrote:
>
>> class ContactForm(forms.Form):
>> subject = forms.CharField(max_length=100)
>> message = forms.CharField()
>> sender = forms.EmailField()
>> cc_myself = forms.BooleanField()
>>
>
> Try cc_myself = forms.BooleanField(required=False)
>
> It defaults to requiring the check to keep the same behaviour as all
> the other fields (i.e. required=True)
> The default is probably the more rare use-case ("I agree to terms/
> conditions"), but it keeps consistency across all our fields.
>
>
> >
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Merged Per Object Permissions (RLP) Branch
Hey Everyone, I know I've gone missing the past few months, been busy finishing off my last semester at school and recovering from some surgeries. I hope to start working on the RLP branch once again, I've merged the RLP branch to the latest trunk. I've gone through and fixed up some stuff (generic relations being moved, and changing the import for forms, etc) but I need to put some more work into it. I have only started to review the newforms and will look into integrating them into RLP and hopefully improving the RLP admin interface. Please let me know of any problems, complaints, compliments, etc. with the RLP branch. I apologize for my absence and disappearance. Cheers, Chris --~--~-~--~~~---~--~~ 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: Bug with generic relations that span other relationships?
On Sun, 2007-06-17 at 20:25 +, [EMAIL PROTECTED] wrote:
> The call to Comment.objects.filter(poll=p) generates the following raw
> SQL (comment columns are replaced by * for brevity):
> SELECT * FROM "comments_comment" LEFT OUTER JOIN "comments_comment" AS
> "m2m_comments_comment__poll" ON "comments_comment"."id" =
> "m2m_comments_comment__poll"."object_id" WHERE
> ("m2m_comments_comment__poll"."object_id" = 47)
>
> Clearly, we have an incorrect join here. It makes no sense to join
> the comments_comment table on itself.
This looks very much like the same behaviour as I reported in ticket
#3906.
Jamie
--~--~-~--~~~---~--~~
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: Volunteering for "Week in Review" postings
*Ping* Update on "week in review" postings? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
contrib.thumbnails approval?
Thanks Michel, those bugs all fixed. Changing this thread's tact, this ticket s still sitting as design decision required - what's the core's thinking now? Is it the sort of thing we want in contrib? I was thinking that perhaps this could alternately go in an `images` contrib package in case there are other related image functions (the captcha image generator discussed in the users group for example) --~--~-~--~~~---~--~~ 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: possible deficiency in newform BooleanField?
On Jun 18, 8:44 am, Mike H <[EMAIL PROTECTED]> wrote:
> class ContactForm(forms.Form):
> subject = forms.CharField(max_length=100)
> message = forms.CharField()
> sender = forms.EmailField()
> cc_myself = forms.BooleanField()
Try cc_myself = forms.BooleanField(required=False)
It defaults to requiring the check to keep the same behaviour as all
the other fields (i.e. required=True)
The default is probably the more rare use-case ("I agree to terms/
conditions"), but it keeps consistency across all our fields.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
possible deficiency in newform BooleanField?
Hi all, Perhaps I'm not using it correctly, but I'm not able to use the BooleanField in newforms in the way the documentation suggests I should be able to. Here's the example : class ContactForm(forms.Form): subject = forms.CharField(max_length=100) message = forms.CharField() sender = forms.EmailField() cc_myself = forms.BooleanField() When I have that in my template, outputted as a table using form.as_table(), the BooleanField is rendered as a checkbox. All well and good so far. The problem comes when I do NOT want to check the "cc myself" box. When the data comes back into my view through POST, I construct the form like this : form = ContactForm(request.POST) Now form.is_valid() is false. This is because when you do not check the checkbox, the browser does not send that field at all in POST, whereas BooleanField expects a False value to come in. In the unit tests for newforms, this happens. When you use an actual browser, this will never happen. Am I using it wrong, or is it a deficiency in BooleanField? For the moment I'm having to copy POST, check for the "cc_field" key and put a False in there if it does not exist. Cheers, Mike --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug with generic relations that span other relationships?
I can't seem to get this sort of functionality to work in Django using
GenericRelation/Foreign key components. For some background, the
motivation behind such a relationship would be to get a list of
generic objects (Comments) on something it's related to (Articles,
Polls, etc) whose related object matches a certain constraint
(polls.id = 47, polls.views>10). Currently, this functionality seems
broken. Of course, some types of queries are fairly simple that can
be achieved with some explicitness:
Comment.objects.filter(content_type=ContentType.objects.get_for_model(p)).filter(object_id=p.id)
Where p is our poll. But it doesn't allow for any real relationship
constraints. For example, I fail to see how would you could extend
the above to include all comments on polls with views > 10? The above
still only works on relationships within the Comment table (columns
object_id and content_type).
My first solution to this problem would be to just to do something
like:
Comment.objects.filter(poll__views__gt=10)
This doesn't work. It doesn't 'fail' in the sense that it gives me
some runtime error. It just returns bogus data. Lets take a look at
a simpler query that we know works with the explicit strategy
mentioned above:
Comment.objects.filter(poll=p)
I'd imagine that this statement should return the same thing as:
Comment.objects.filter(content_type=ContentType.objects.get_for_model(p)).filter(object_id=p.id)
But it doesn't. In fact, it just returns with several, identical
Comment rows with object_id = p.id, not the desired result at all!
Here is what happens under the hood (assuming p.id = 47 and
content_type_id for Polls is 12):
The call to Comment.objects.filter(poll=p) generates the following raw
SQL (comment columns are replaced by * for brevity):
SELECT * FROM "comments_comment" LEFT OUTER JOIN "comments_comment" AS
"m2m_comments_comment__poll" ON "comments_comment"."id" =
"m2m_comments_comment__poll"."object_id" WHERE
("m2m_comments_comment__poll"."object_id" = 47)
Clearly, we have an incorrect join here. It makes no sense to join
the comments_comment table on itself.
We should instead be doing something along the lines of:
SELECT * FROM "comments_comment" INNER JOIN "polls_poll" ON
("comments_comment"."content_type_id" =12 AND
"comments_comment"."object_id" ="polls_poll".id) WHERE
("polls_poll"."id" = 47) ;
Here, we join comments_comment on the polls_poll table and match up
the type of comment (content_type_id=12, a poll) with the comment's
object_id = polls_poll.id.
Is this type of query known to be broken? If so, why isn't it
asserting instead, telling me I can't make such queries? Any insight
would be appreciated before I make an effort to understand this
generic relation code.
Thanks!
--~--~-~--~~~---~--~~
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: Newforms StrippedCharField
On 6/13/07, Norman Harman <[EMAIL PROTECTED]> wrote:
>
> Kind of think CharField should do this, but I can imagine someone not
> wanting it.
>
> class StrippedCharField(forms.CharField):
> """
> Newforms CharField that strips trailing and leading spaces
> """
> def clean(self, value):
> if value is not None:
> value = value.strip()
> return super(StrippedCharField, self).clean(value)
In case where an automatically stripping charfield is needed it's a
quite trivial task to create one. However, adding such model to the
Django is probably not useful, since it doesn't bring any value to
current form fields.
Making the stripping behavior to be the default for CharField would be
even worse: Think about password field, which depends heavily on
CharField implementation. Now, the user would like to change her
password from "foo" to "bar " (note the trailing space). The charfield
would trim out the trailing space and make it impossible for the user
to log in using the password she thought she changed.
> I also hacked this together, comments/improvements welcomed.
>
> class ChangePasswordForm(forms.Form):
> password = forms.CharField(max_length=32, min_length=6,
> widget=PasswordInput
> confirm = forms.CharField(max_length=32, min_length=6,
> widget=PasswordInput
>
> def clean(self):
> print self.cleaned_data['password'], self.cleaned_data['confirm']
> if self.cleaned_data['password'] != self.cleaned_data['confirm']:
> raise ValidationError("Passwords do not match.")
> return self.cleaned_data
Comments for the custom forms created should probably be asked from
the Django Users mailing list
- Jyrki
--
Jyrki // [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: "Possesive" filter
Whoops, just saw I had "possessive" spelled incorrectly... revised the patch! Cheers, MikeH --- django0.96/template/defaultfilters.py 2007-03-10 08:11:28.0 + +++ django/template/defaultfilters.py 2007-06-17 20:02:50.0 +0100 @@ -551,6 +551,15 @@ pass return singular_suffix +def possessive(value): +""" +Returns a possessive form of a name according to English rules +Mike returns Mike's, while James returns James' +""" +if value[-1] == 's': +return "%s'" % value +return "%s's" % value + def phone2numeric(value): "Takes a phone number and converts it in to its numerical equivalent" from django.utils.text import phone2numeric @@ -593,6 +602,7 @@ register.filter(make_list) register.filter(phone2numeric) register.filter(pluralize) +register.filter(possessive) register.filter(pprint) register.filter(removetags) register.filter(random) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"Possesive" filter
Hi all, I needed a nice way of saying "mike's friends" in a template when the currently logged in user was "mike", but "james' friends" when it was james. I realise this is a very English biased filter, but here's a patch to add it to defaultfilters in template. Cheers, MikeH --- django0.96/template/defaultfilters.py 2007-03-10 08:11:28.0 + +++ django/template/defaultfilters.py 2007-06-17 20:02:50.0 +0100 @@ -551,6 +551,15 @@ pass return singular_suffix +def possesive(value): +""" +Returns a possesive form of a name according to English rules +Mike returns Mike's, while James returns James' +""" +if value[-1] == 's': +return "%s'" % value +return "%s's" % value + def phone2numeric(value): "Takes a phone number and converts it in to its numerical equivalent" from django.utils.text import phone2numeric @@ -593,6 +602,7 @@ register.filter(make_list) register.filter(phone2numeric) register.filter(pluralize) +register.filter(possesive) register.filter(pprint) register.filter(removetags) register.filter(random) --~--~-~--~~~---~--~~ 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: International standard for date and time
On 17 jun, 02:01, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > (also the patch should have been against > global_settings.py, not settings.py, but that's a minor thing). It's already corrected. --~--~-~--~~~---~--~~ 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: International standard for date and time
On 17 jun, 09:03, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2007-06-17 at 00:54 -0700, Tai Lee wrote: > > +1 - it's a simple default settings change. django is used by an > > international community, so the defaults should be a format that is > > understood by everybody without any possibility of ambiguity. those > > that prefer a different format (american, or abbreviated or full > > length month names etc) can change their settings. > > The current settings already are unambiguous. The current settings already are unambiguous *only for north americans*. Django is a project used by an international community (and grown by that community) and its configuration should be set to an international format by default. --~--~-~--~~~---~--~~ 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: Return unicode from template's render
On Sun, 2007-06-17 at 12:15 +0400, Ivan Sagalaev wrote: > Hello everyone (and Malcolm especially)! > > This is about template rendering in unicode branch. Template's render > now returns a byte string encoded in a DEFAULT_CHARSET. However just > yesterday I've come across a case where a developer needed to render a > template not to send it over HTTP connection but for some internal > usage. It was then concatenated to some other unicode strings and failed > with UnicodeDecodeError doing implicit unicode(). Then it striked me > that we encode rendered output just for sending it over a wire and it > should be handled in HttpResponse and send_email. In fact HttpResponse > already encodes unicode objects using DEFAULT_CHARSET. Not sure about > email machinery. That sounds reasonable. 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 -~--~~~~--~~--~--~---
Return unicode from template's render
Hello everyone (and Malcolm especially)! This is about template rendering in unicode branch. Template's render now returns a byte string encoded in a DEFAULT_CHARSET. However just yesterday I've come across a case where a developer needed to render a template not to send it over HTTP connection but for some internal usage. It was then concatenated to some other unicode strings and failed with UnicodeDecodeError doing implicit unicode(). Then it striked me that we encode rendered output just for sending it over a wire and it should be handled in HttpResponse and send_email. In fact HttpResponse already encodes unicode objects using DEFAULT_CHARSET. Not sure about email machinery. --~--~-~--~~~---~--~~ 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: International standard for date and time
On Sun, 2007-06-17 at 00:54 -0700, Tai Lee wrote: > +1 - it's a simple default settings change. django is used by an > international community, so the defaults should be a format that is > understood by everybody without any possibility of ambiguity. those > that prefer a different format (american, or abbreviated or full > length month names etc) can change their settings. The current settings already are unambiguous. 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: International standard for date and time
+1 - it's a simple default settings change. django is used by an international community, so the defaults should be a format that is understood by everybody without any possibility of ambiguity. those that prefer a different format (american, or abbreviated or full length month names etc) can change their settings. --~--~-~--~~~---~--~~ 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: template rendering as iteration, instead of layered concatenation
On Thu, 2007-06-14 at 12:23 -0700, Brian Harring wrote: > Just filed ticket 4565, which basically converts template rendering > away from "build a string within this node of subnode results, return > it, wash rinse repeat", and into "yield each subnode chunk, and my > data as it's available". > > The pros of it are following (copy/pasting from the ticket): > > * instant results; as long as you don't have any tags/nodes that > require collapsing their subtree down into a single string, data is > sent out immediately. Rather nice if you have a slow page- you start > getting chunks of the page immediately, rather then having to wait for > the full 10s/whatever time for the page to render. > > * Far less abusive on memory; usual 'spanish inquisition' heavy > test test (term coined by mtreddinick, but it works), reduction from > 84m to 71m for usage at the end of rendering. What I find rather > interesting about that reduction is that the resultant page is 6.5 > mb; the extra 7mb I'm actually not sure where the reduction comes > from (suspect there is some copy idiocy somewhere forcing a new > string)- alternatively, may just be intermediate data hanging around, > since I've been working with this code in one form or another for 3 > months now, and still haven't figured out the 'why' for that diff. There was one subtle bug whose fix negates these improvements in some cases: if any middleware needs access to the contents of the response, we need to store a copy of the stringified response content. Since the iterator version isn't rewindable, you get to access the iterators once only. That's handled automatically, though, so it's only a penalty in the necessary cases and never a development burden. Other than that (and a few minor formatting things), the patch was fine. All committed now -- along with protection against infinite looping in render(). Thanks, 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 -~--~~~~--~~--~--~---
