Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Tai Lee
http://code.djangoproject.com/ticket/7581 Just posted this ticket with an initial patch (sans documentation changes and tests). Basically there are several middleware classes that access HttpResponse.content directly which break streaming HttpResponse objects that use a generator to yield

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Ivan Sagalaev
Tai Lee wrote: > http://code.djangoproject.com/ticket/7581 > > Just posted this ticket with an initial patch (sans documentation > changes and tests). Basically there are several middleware classes > that access HttpResponse.content directly which break streaming > HttpResponse objects that use

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread [EMAIL PROTECTED]
On Jun 25, 11:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Two things: > > > I don't know the background of whether Tom tried these things or not. > Again, I don't care to ague about it. Let's not make this happen again > in the future, OK? > > Please, folks, we're all friends here.

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Malcolm Tredinnick
On Tue, 2008-07-01 at 00:03 -0700, Tai Lee wrote: > http://code.djangoproject.com/ticket/7581 > > Just posted this ticket with an initial patch (sans documentation > changes and tests). Basically there are several middleware classes > that access HttpResponse.content directly which break

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread Kenneth Gonsalves
On 26-Jun-08, at 7:51 PM, Jeremy Dunck wrote: >> Then, I tried helping people the way he does for a mere fraction of >> the time he does. Answering the same 5 questions 20 times a day >> (ok, I >> did it maybe twice) would drive anyone insane. > > +1 +1 > > Yes, it'd be nice if Magus were a

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Ivan Sagalaev
Malcolm Tredinnick wrote: > I thought we'd fixed it, but apparently we haven't: if any iterator is > passed into an HttpResponse, it should be converted to a string > immediately so that things can index into it without doing > non-repeatable consumption. Malcolm, sorry, that won't work. I've

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Malcolm Tredinnick
On Tue, 2008-07-01 at 14:02 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > I thought we'd fixed it, but apparently we haven't: if any iterator is > > passed into an HttpResponse, it should be converted to a string > > immediately so that things can index into it without doing > >

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Ivan Sagalaev
Malcolm Tredinnick wrote: > Any middleware that examines the content has to pull the content into > memory in case it's an iterator. If they don't they're buggy because > they're consuming the content ahead of the web server. Agreed. > But the default behaviour shouldn't > require repetitive

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Malcolm Tredinnick
On Tue, 2008-07-01 at 14:42 +0400, Ivan Sagalaev wrote: > Malcolm Tredinnick wrote: > > Any middleware that examines the content has to pull the content into > > memory in case it's an iterator. If they don't they're buggy because > > they're consuming the content ahead of the web server. > >

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Ivan Sagalaev
Malcolm Tredinnick wrote: > The response should just return a copy of the > content when response.content is accessed, which means turning any > iterator into a proper string. Ouch.. I thought it already does just that. Yeah, it's a bug then. Though simple to fix. > But it *does* require that

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Tai Lee
Certainly the implementation of the patch is not ideal (by accessing private attributes on HttpResponse), which is why I brought it up for discussion before going any further. I do feel that there is a real benefit and even requirement in some cases to supporting streaming HttpResponse objects.

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

2008-07-01 Thread Tai Lee
On Jul 1, 7:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > It's quite a large restriction to say that no middleware should ever try > to examine the contents of the HttpResponse since it might be an > iterator that shouldn't be consumed. You're proposing a bunch of > specific changes

House Wife Hot Sexy Videos In First Night & Aunty's Phone Number

2008-07-01 Thread surya
WEB CAM ON ONLINE New Web cam Software Simply Five Step To Open Ur Computer 1.Visit Link===> http://www.moreinfo247.com/9560073/CB 2.sign up with your current email id also. 3.then check your mail id(sfi message mail) 4.click the that mail and click 2 link. 5.after 2 minutes

XMLField in nfa

2008-07-01 Thread Alex Rades
Hi, I'm trying to understand what's wrong with the XMLField in nfa. The validation in validators.py/RelaxNGCompact is never called, It looks like unused dead code. This means the validation on XMLFields is currently not working at all. Is there anyone with a better understanding of the situation?

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread Tom Tobin
On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > why should he be more polite? He follows the policy of 'teaching to > fish' rather than spoonfeeding. I have several times got flamed by > him for getting impatient and giving the answer. I would say that he > is the

Re: XMLField in nfa

2008-07-01 Thread David Danier
> I'm trying to understand what's wrong with the XMLField in nfa. > The validation in validators.py/RelaxNGCompact is never called, It looks > like unused dead code. This means the validation on XMLFields is > currently not working at all. > Is there anyone with a better understanding of the

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread Rajeev J Sebastian
+1 to Tom, though magus On Tue, Jul 1, 2008 at 7:34 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves > <[EMAIL PROTECTED]> wrote: >> >> why should he be more polite? He follows the policy of 'teaching to >> fish' rather than spoonfeeding. I have several

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread Honza Král
that would look really terrible with the hashes in the URL, that's why I avoided GET, it would be easy to factor it out and even allow for data to be passed in URL (I have no idea why somebody would want that, but why not ;) ) but I just don't think it would make sense. Forms aren't just for

Re: XMLField in nfa

2008-07-01 Thread Alex Rades
Shouldn't this be marked as somewhat blocking for 1.0-alpha? Is there any good reason why the code you wrote has not been accepted? On Tue, Jul 1, 2008 at 6:46 PM, David Danier <[EMAIL PROTECTED]> wrote: > > > I'm trying to understand what's wrong with the XMLField in nfa. > > The validation in

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread David Cramer
I'll agree Magus is harsh, but he's also helpful, and this isn't the place to discuss this :) On Jul 1, 11:40 am, "Rajeev J Sebastian" <[EMAIL PROTECTED]> wrote: > +1 to Tom, though magus > > On Tue, Jul 1, 2008 at 7:34 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 4:25 AM,

Re: newforms rendering and MVC pattern

2008-07-01 Thread David Cramer
I personally like the rendering methods being attached to the form, as they don't make sense as a universal template filter/tag. I do however, use a filter as "as_p" doesn't do much :) On Jun 28, 8:33 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-06-28 at 06:12 -0700, ionut

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread Ludvig Ericson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 1, 2008, at 18:56, Honza Král wrote: > That's -1 from me. I am not opposed to the idea in general, I just > don't feel it's needed and should be in the code. Sounds more like a -0 to me. -1 is, as far as I have seen, strong rejection.

Re: Call for testing: streaming uploads (#2070)

2008-07-01 Thread Jonathan Hseu
I mentioned some issues to Michael Axiak a while back, and he said he'd get to them but that I should post them on the 2070 ticket. I forgot to post them, so he might've missed it before it was committed to SVN. I made a new ticket for them: http://code.djangoproject.com/ticket/7593 A quick

Paginator vs. QuerySetPaginator

2008-07-01 Thread Jeremy Dunck
I just ran into the same issue several people before me have: Paginator is a bit dangerous when handed a queryset, and QuerySetPaginator should be used instead. This ticket exists, but no core dev has contributed to discussion yet. http://code.djangoproject.com/ticket/7478 I'd like to avoid

Re: Call for testing: streaming uploads (#2070)

2008-07-01 Thread David Cramer
I haven't read this over in too much detail yet (I just auto ignore the 10k trac emails about it :P) but a few concerns: - Is there a setting (e.g. settings.py) to restrict the maximum file size in an upload? - For test suites couldn't you while (xrange(n)) pass /dev/random or whatever to make a

Re: Call for testing: streaming uploads (#2070)

2008-07-01 Thread Jeremy Dunck
On Tue, Jul 1, 2008 at 4:40 PM, David Cramer <[EMAIL PROTECTED]> wrote: > - Is there a setting (e.g. settings.py) to restrict the maximum file > size in an upload? FILE_UPLOAD_MAX_MEMORY_SIZE --~--~-~--~~~---~--~~ You received this message because you are

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread David Durham, Jr.
On Mon, Jun 30, 2008 at 8:03 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > I was thinking the FormWizard should allow GET to be used on all but > the last step, or should allow configuration of what to method to use. > > Forms aren't just for posting. > > Any interest in this? Nice thing about

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread David Durham, Jr.
On Tue, Jul 1, 2008 at 4:59 PM, David Durham, Jr. <[EMAIL PROTECTED]> wrote: > form, and are redirected to a GET for the next step. In this case, > the POST disappears from the user's history (refresh and reload work > as expected). Sorry, reload and back work as expected ... -Dave

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread Waylan Limberg
On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. <[EMAIL PROTECTED]> wrote: > > Nice thing about GETs is that users aren't confronted with the dreaded > "Data was submitted with POST" confirmation, which is confusing to > most people and usually not tested. Basically you end up breaking the >

Re: XMLField in nfa

2008-07-01 Thread David Danier
> Shouldn't this be marked as somewhat blocking for 1.0-alpha? Personally I would remove XmlField from the standard-models and create something like django.contrib.xml, which includes some common code for xml-handling (forms, models, dom/etree/..., xslt with callbacks, etc). But thats nothing

Re: Call for testing: streaming uploads (#2070)

2008-07-01 Thread Jacob Kaplan-Moss
On Tue, Jul 1, 2008 at 2:40 PM, David Cramer <[EMAIL PROTECTED]> wrote: > I haven't read this over in too much detail yet (I just auto ignore > the 10k trac emails about it :P) but a few concerns: I haven't read the rest of your email yet, but I think the answers are "77" and "see a doctor if

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread Arien
On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. > <[EMAIL PROTECTED]> wrote: >> >> Nice thing about GETs is that users aren't confronted with the dreaded >> "Data was submitted with POST" confirmation, which is

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread David Durham, Jr.
On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > Um, this is intentional and a good thing. If you read the spec, not > only is the difference between GET and POST defined, but the way user > agents (browsers) should treat them is defined as well. Breaking the > back &

Re: FormWizard - GETs on all but last step?

2008-07-01 Thread Waylan Limberg
On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: >> >> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr. >> <[EMAIL PROTECTED]> wrote: >>> >>> Nice thing about GETs is that users aren't confronted with

Re: Paginator vs. QuerySetPaginator

2008-07-01 Thread Gary Wilson Jr.
Jeremy Dunck wrote: > I just ran into the same issue several people before me have: > Paginator is a bit dangerous when handed a queryset, and > QuerySetPaginator should be used instead. > > This ticket exists, but no core dev has contributed to discussion yet. >

Re: Community representation, or, #django user "Magus-" needs to go far away

2008-07-01 Thread Kenneth Gonsalves
On 01-Jul-08, at 10:04 PM, Tom Tobin wrote: > On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves > <[EMAIL PROTECTED]> wrote: >> >> why should he be more polite? He follows the policy of 'teaching to >> fish' rather than spoonfeeding. I have several times got flamed by >> him for getting

Re: Spam detection

2008-07-01 Thread Gary Wilson Jr.
Jacob Kaplan-Moss wrote: > Help me out here: how can I make it more obvious? Wow, you've certainly made it more obvious :) I pity the fool that misses it now. Gary --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups