Re: Paginator vs. QuerySetPaginator
Hi, On Wed, 02 Jul 2008 05:55:26 +0200, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote: > Jeremy Dunck wrote: [Pagintor problems] >> Is there some other way we can point the gun away from our foot? > > I, for one, would be in favor of doing away with QueryPaginator and > bringing back the behaviour of the _get_count() method of the lecacy > ObjectPaginator: > > def _get_count(self): > # The old API allowed for self.object_list to be either a QuerySet > or a > # list. Here, we handle both. > if self._count is None: > try: > self._count = self.object_list.count() > except TypeError: > self._count = len(self.object_list) > return self._count > count = property(_get_count) > > The legacy _get_count first tries to do object_list.count() with no > arguments. That raises a TypeError if object_list is a list, since > list.count() requires an argument. If the TypeError is raised, then > _get_count falls back to using len(object_list). > > Seems like this is a nice interface, either have your object_list > provide a count() method or rely on len(object_list). I believe this > sort of duck typing would be better than an explicit type check. > > Then, we would have no dangers when passing a QuerySet, no confusion as > to which Paginator class to use, and the ability to accept any other > "object_list" instance that has a count() method or can have len() > called on it. > There is an open ticket for this: http://code.djangoproject.com/ticket/7478 If the consens is that this should go in (I'm not sure who mrts is), I could create a patch for this. The docs probably need updating too. Regards adi --~--~-~--~~~---~--~~ 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: Spam detection
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 "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: Community representation, or, #django user "Magus-" needs to go far away
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 impatient and giving the answer. I would say that he >> is the single most important person in the channel. He has even taken >> the trouble of writing a script whereby he can generate almost >> instantaneous references to the *relevant* docs. It is easy to give >> direct answers - difficult, irritating and time consuming to 'teach >> to fish'. Let him be as rude as he wants, as long as he is there. > > Stepping back for a moment from the way I approached this issue — > which I readily admit was the wrong way to do it, and which I > apologize to the community for — and the parties in question, I'm > concerned with the general sentiment expressed in this thread. It is > quite understandable to be grateful to someone for performing a > difficult task; it's another thing to allow that gratitude to mute > necessary criticism. I think there's room in our community for both > charity *and* civility; if we can improve, we *should* improve. actually this debate belongs on django-users (which is why I put in my 2 paise) - I think if taken there we can get a real measure of the pros of his help against the cons of his curtness at times (I wouldn't call it being rude) -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/code/ --~--~-~--~~~---~--~~ 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: Paginator vs. QuerySetPaginator
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. > http://code.djangoproject.com/ticket/7478 > > I'd like to avoid making it dangerously easy to consume memory/cpu on > the full queryset. > > isinstance(object_list, QuerySet) is a fairly straightforward way to > collapse Paginator and QuerySetPaginator into a single class. > > Are we not doing that because it'd mean importing django.db into a > django.core object? > > Is there some other way we can point the gun away from our foot? I, for one, would be in favor of doing away with QueryPaginator and bringing back the behaviour of the _get_count() method of the lecacy ObjectPaginator: def _get_count(self): # The old API allowed for self.object_list to be either a QuerySet or a # list. Here, we handle both. if self._count is None: try: self._count = self.object_list.count() except TypeError: self._count = len(self.object_list) return self._count count = property(_get_count) The legacy _get_count first tries to do object_list.count() with no arguments. That raises a TypeError if object_list is a list, since list.count() requires an argument. If the TypeError is raised, then _get_count falls back to using len(object_list). Seems like this is a nice interface, either have your object_list provide a count() method or rely on len(object_list). I believe this sort of duck typing would be better than an explicit type check. Then, we would have no dangers when passing a QuerySet, no confusion as to which Paginator class to use, and the ability to accept any other "object_list" instance that has a count() method or can have len() called on it. Gary --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
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 the dreaded >>> "Data was submitted with POST" confirmation, which is confusing to >>> most people and usually not tested. Basically you end up breaking the >>> back button and the reload button. >> >> 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 & reload buttons is a requirement of the spec to, among other >> reasons, avoid multiple posts by impatient (or double-clicking) users. >> Granted, browsers could provide more helpful messages, but we want >> that behavior for POSTing data. > > What specification requires this? > A number of them actually. To name a few: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9 http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13 http://www.w3.org/2001/tag/doc/whenToUseGet.html A decent summary of the issues are found here: http://www.cs.tut.fi/~jkorpela/forms/methods.html -- Waylan Limberg [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: FormWizard - GETs on all but last step?
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 & reload buttons is a requirement of the spec to, among other > reasons, avoid multiple posts by impatient (or double-clicking) users. > Granted, browsers could provide more helpful messages, but we want > that behavior for POSTing data. Keep in mind that your average user doesn't care what a spec says about HTTP. I know the spec (well enough) and I agree that a browser should not allow people to accidentally POST by refreshing the page. That is the whole point of POSTing where it's needed (substantial amounts of form data or something that changes the state of the system), and redirect to GET the next page, since retrieving the next page should not be a problem regardless of how many times you do that. Anyway, a lot of users don't understand what the POST warning is about, and they'll rePOST anyway. If you POST then redirect to GET, you remove the POST from their history and don't (necessarily) have to worry about them POSTing by mistake. Clicking back to GET the previous page (perhaps from cache) should not be a problem either, and if it is, we can do better than a confusing browser confirmation dialog. (set the expiry policy properly and use the session scope to detect a problem and provide instructions to the user) > Perhaps he wants to allow the user to stop part way through a wizard, > bookmark the url (with the data entered thus far preserved in the > querystring), and allow them to pick up where they left off later.? > Interesting, but I wouldn't recommend it. For one, that could result > in some long urls (perhaps even longer than the limit). A multi-part > form could add up to a lot pretty quick. Second, those would be some > ugly urls. And third, as mentioned above, it's not really the proper > use of GET anyway. Well, the encoding multiple pages of form values in the URL is going to be problematic because of the issue I mentioned where servers will not work with ridiculously long URLs. My thinking is this is a case where using the session scope is valuable. I'm honestly a django newbie so I can't say much about the problems of storing forms in session scope. You could easily store some object, even just a dictionary or sequence of dictionaries representing the wizard state somewhere else and populate the form values on the GET pageX request. Session is handy but also storing elsewhere in case someone's session times out or they want to bookmark is nice. > So, unless a strong use-case is provided, I'm -1 on this. There's definitely a strong use-case for mere form display to be a GET not a POST. This is web-wizards 101. Believe me, I've written some wizards. -Dave --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
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 confusing to >> most people and usually not tested. Basically you end up breaking the >> back button and the reload button. > > 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 & reload buttons is a requirement of the spec to, among other > reasons, avoid multiple posts by impatient (or double-clicking) users. > Granted, browsers could provide more helpful messages, but we want > that behavior for POSTing data. What specification requires this? > Which leads me to the question: In what use-case would a FormWizard > ever GET? GET is only to be used to retrieve data (i.e.: search > results) whereas POST should be used when submitting data to the > server. I can't think of any case where a multi-page form would be > used to "retrieve" data. I realize Jeremy suggested that POST would > still be used on the final page, but even so, the other pages > technically are still POSTing data. The other pages are obviously retrieving the form to be filled in to complete the next step. > Perhaps he wants to allow the user to stop part way through a wizard, > bookmark the url (with the data entered thus far preserved in the > querystring), and allow them to pick up where they left off later.? > Interesting, but I wouldn't recommend it. For one, that could result > in some long urls (perhaps even longer than the limit). A multi-part > form could add up to a lot pretty quick. Second, those would be some > ugly urls. And third, as mentioned above, it's not really the proper > use of GET anyway. I fail to see how the perceived beauty of the generated URLs matters? Depending on the situation, using GET for various pages of a wizard-style interaction may be exactly the right thing to do. This doesn't seem to mesh nicely with the way things work in FormWizard's world, though. Arien --~--~-~--~~~---~--~~ 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: Call for testing: streaming uploads (#2070)
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 the rash doesn't go away." Seriously, David, please read the at *least* the docs before asking questions. Your first question is pretty obviously answered by a glance at settings.txt. > - For test suites couldn't you while (xrange(n)) pass /dev/random or > whatever to make a larger file upload simulation? That's basically what the test does (well, "a" * 10MB, not /dev/random). Unfortunately the way the test suite works the file gets all read into memory anyway (by the test suite, that is) so we can't make it too big without making the test suite more expensive than it already is. 10MB is a fine test that stream-to-disk works, and for tests of large files I'm OK relying on anecdotal evidence that it works. Jacob --~--~-~--~~~---~--~~ 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: XMLField in nfa
> 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 I decide. > Is there > any good reason why the code you wrote has not been accepted? #3094 is accepted, but there has not been any (visible) progress for some time. So there will be a better solution, just be patient. About my code: This is far from being ready for checkin. I just posted some code that works here, but it doesn't fit into django in its current state. Greetings, David Danier --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
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 > back button and the reload button. 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 & reload buttons is a requirement of the spec to, among other reasons, avoid multiple posts by impatient (or double-clicking) users. Granted, browsers could provide more helpful messages, but we want that behavior for POSTing data. Which leads me to the question: In what use-case would a FormWizard ever GET? GET is only to be used to retrieve data (i.e.: search results) whereas POST should be used when submitting data to the server. I can't think of any case where a multi-page form would be used to "retrieve" data. I realize Jeremy suggested that POST would still be used on the final page, but even so, the other pages technically are still POSTing data. Perhaps he wants to allow the user to stop part way through a wizard, bookmark the url (with the data entered thus far preserved in the querystring), and allow them to pick up where they left off later.? Interesting, but I wouldn't recommend it. For one, that could result in some long urls (perhaps even longer than the limit). A multi-part form could add up to a lot pretty quick. Second, those would be some ugly urls. And third, as mentioned above, it's not really the proper use of GET anyway. So, unless a strong use-case is provided, I'm -1 on this. -- Waylan Limberg [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: FormWizard - GETs on all but last step?
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 --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
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 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 back button and the reload button. Having a working reload button is nice for developers, and a working back button is really nice for users. There's a POST redirect to GET pattern where users POST a 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). I don't know a lot about Django's Form wizard, but it looks like it's hashing values in a hidden field, which would require use of the session scope (or maybe RoRs "flash" but that would break the reload button) so that you don't end up with a hash in the URL. Putting the hash in the url isn't necessarily an option because most web servers limit the length of URLs to something reasonable. -Dave --~--~-~--~~~---~--~~ 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: Call for testing: streaming uploads (#2070)
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 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: Call for testing: streaming uploads (#2070)
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 larger file upload simulation? On Jul 1, 3:56 pm, Jonathan Hseu <[EMAIL PROTECTED]> wrote: > 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 overview of the issues: > 1. The temporary file is not deleted in many cases. This is a problem > when handling large uploads. The fix is to use tempfile.TemporaryFile > instead of uploadhandler.py's TemporaryFile (why does it even > exist?). tempfile.TemporaryFile unlinks the file immediately after > creation. uploadhandler.py's TemporaryFile also does not act > completely like a file object, which would be fixed by moving to > tempfile.TemporaryFile. > 2. An extremely common use-case requires direct access to the file > object. Both upload handlers (memory & temporary file) have file > objects that UploadedFile can return, so why not put it in the API? > > Thanks, > Jonathan Hseu > > On Jun 26, 2:14 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > > Hi folks -- > > > As far as I'm concerned, #2070, adding large streaming uploads, is > > done. I'd like to get some public kicking-of-the-tires before I push > > the change to trunk (which won't happen before Tuesday: I'm taking a > > long weekend off). > > > You can get the code either from my git repository > > (git://djangoproject.com/django; branch "2070-streaming-uploads") or > > as a patch against [7728] > > fromhttp://code.djangoproject.com/attachment/ticket/2070/2070-r7728.patch. > > There's also a > > gitweb:http://code.djangoproject.com/git/?p=django;a=shortlog;h=refs/heads/2 > > > Documentation of the new features is can be found in > > ``docs/upload_handling.txt`` > > orhttp://code.djangoproject.com/git/?p=django;a=blob_plain;f=docs/uploa > > > I need a hand on the following things: > > > * Running the test suite -- coverage is quite good now, but I've only > > been able to test on a limited set of OSes/DBs. Looks elsewhere just > > in case, very good. > > > * Real-world tests -- try uploading huge files. I can't really > > simulate enormous files in the test suite, so someone willing to > > upload a bunch of porn^H^H^H^H video would help. > > > * Custom upload handlers: write some, and let me know how it goes. > > > Also, anyone with better git-fu than me might want to try merging this > > into the newforms-admin branch to see if anything crazy blows up; I > > don't have any idea how this'll affect that (though I hope it won't). > > > Please report any problems back here; the ticket is nearly impossible > > to follow now. > > > Thanks! > > > Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Paginator vs. QuerySetPaginator
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 making it dangerously easy to consume memory/cpu on the full queryset. isinstance(object_list, QuerySet) is a fairly straightforward way to collapse Paginator and QuerySetPaginator into a single class. Are we not doing that because it'd mean importing django.db into a django.core object? Is there some other way we can point the gun away from our foot? --~--~-~--~~~---~--~~ 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: Call for testing: streaming uploads (#2070)
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 overview of the issues: 1. The temporary file is not deleted in many cases. This is a problem when handling large uploads. The fix is to use tempfile.TemporaryFile instead of uploadhandler.py's TemporaryFile (why does it even exist?). tempfile.TemporaryFile unlinks the file immediately after creation. uploadhandler.py's TemporaryFile also does not act completely like a file object, which would be fixed by moving to tempfile.TemporaryFile. 2. An extremely common use-case requires direct access to the file object. Both upload handlers (memory & temporary file) have file objects that UploadedFile can return, so why not put it in the API? Thanks, Jonathan Hseu On Jun 26, 2:14 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hi folks -- > > As far as I'm concerned, #2070, adding large streaming uploads, is > done. I'd like to get some public kicking-of-the-tires before I push > the change to trunk (which won't happen before Tuesday: I'm taking a > long weekend off). > > You can get the code either from my git repository > (git://djangoproject.com/django; branch "2070-streaming-uploads") or > as a patch against [7728] > fromhttp://code.djangoproject.com/attachment/ticket/2070/2070-r7728.patch. > There's also a > gitweb:http://code.djangoproject.com/git/?p=django;a=shortlog;h=refs/heads/2 > > Documentation of the new features is can be found in > ``docs/upload_handling.txt`` > orhttp://code.djangoproject.com/git/?p=django;a=blob_plain;f=docs/uploa > > I need a hand on the following things: > > * Running the test suite -- coverage is quite good now, but I've only > been able to test on a limited set of OSes/DBs. Looks elsewhere just > in case, very good. > > * Real-world tests -- try uploading huge files. I can't really > simulate enormous files in the test suite, so someone willing to > upload a bunch of porn^H^H^H^H video would help. > > * Custom upload handlers: write some, and let me know how it goes. > > Also, anyone with better git-fu than me might want to try merging this > into the newforms-admin branch to see if anything crazy blows up; I > don't have any idea how this'll affect that (though I hope it won't). > > Please report any problems back here; the ticket is nearly impossible > to follow now. > > Thanks! > > Jacob --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
-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. Ludvig "toxik" Ericson [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkhqk+0ACgkQXnZ94Kd6KaeegwCgpVjR04QzK+yNIHNuWvzOpR81 s1oAoJKZbPNob7D68n2VqUaVr+It+AKC =+15A -END PGP SIGNATURE- --~--~-~--~~~---~--~~ 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 rendering and MVC pattern
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 wrote: > > I do'nt consider to be a MVC good pattern rendering form html inside > > newforms class. > > A form class is purely presentational, so there's no "MVC" (or whatever > you might want to call it -- you can't do MVC on the web, after all) > violation going on in that respect. > > > I think a better proach while rendering html forms is to use a > > template file > > [...] > > So do that. There's nothing stopping you from implementing whatever > method you like on forms. I've done similar things for some of my forms, > reading the presentation layout from a template for rendering. It's not > necessarily a universal solution, since it requires quite a lot of logic > in the template to handle all cases and can consequently get very messy, > so sometimes the trade-off of placing HTML in the Python code leads to > something that's easier to manage. Sometimes, though, your approach is > easiest (it does keep the HTML and the Python separate, for example). > > Remember, a form is just a class on which you call methods in your > template. So implement the presentation method you call however you > like. > > 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: Community representation, or, #django user "Magus-" needs to go far away
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, 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 single most important person in the channel. He has even taken > >> the trouble of writing a script whereby he can generate almost > >> instantaneous references to the *relevant* docs. It is easy to give > >> direct answers - difficult, irritating and time consuming to 'teach > >> to fish'. Let him be as rude as he wants, as long as he is there. > > > Stepping back for a moment from the way I approached this issue — > > which I readily admit was the wrong way to do it, and which I > > apologize to the community for — and the parties in question, I'm > > concerned with the general sentiment expressed in this thread. It is > > quite understandable to be grateful to someone for performing a > > difficult task; it's another thing to allow that gratitude to mute > > necessary criticism. I think there's room in our community for both > > charity *and* civility; if we can improve, we *should* improve. --~--~-~--~~~---~--~~ 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: XMLField in nfa
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 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? > > AFAIK XmlField is currently not supported in nfa. Even more the current > solution for XML-validation will be replaced, so that django does not > depend on jing any more, see http://code.djangoproject.com/ticket/5620 > and http://code.djangoproject.com/ticket/3094 for details. The second > ticket contains a XML-validator using lxml. > > Greetings, David Danier > > > > > --~--~-~--~~~---~--~~ 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: FormWizard - GETs on all but last step?
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 posting, but in my opinion, when I want to use something like a wizard, I really want POST. 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. Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 On Tue, Jul 1, 2008 at 03:03, 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? > > > > --~--~-~--~~~---~--~~ 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: Community representation, or, #django user "Magus-" needs to go far away
+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 times got flamed by >> him for getting impatient and giving the answer. I would say that he >> is the single most important person in the channel. He has even taken >> the trouble of writing a script whereby he can generate almost >> instantaneous references to the *relevant* docs. It is easy to give >> direct answers - difficult, irritating and time consuming to 'teach >> to fish'. Let him be as rude as he wants, as long as he is there. > > Stepping back for a moment from the way I approached this issue — > which I readily admit was the wrong way to do it, and which I > apologize to the community for — and the parties in question, I'm > concerned with the general sentiment expressed in this thread. It is > quite understandable to be grateful to someone for performing a > difficult task; it's another thing to allow that gratitude to mute > necessary criticism. I think there's room in our community for both > charity *and* civility; if we can improve, we *should* improve. > > > > --~--~-~--~~~---~--~~ 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: XMLField in nfa
> 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? AFAIK XmlField is currently not supported in nfa. Even more the current solution for XML-validation will be replaced, so that django does not depend on jing any more, see http://code.djangoproject.com/ticket/5620 and http://code.djangoproject.com/ticket/3094 for details. The second ticket contains a XML-validator using lxml. Greetings, David Danier --~--~-~--~~~---~--~~ 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: Community representation, or, #django user "Magus-" needs to go far away
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 single most important person in the channel. He has even taken > the trouble of writing a script whereby he can generate almost > instantaneous references to the *relevant* docs. It is easy to give > direct answers - difficult, irritating and time consuming to 'teach > to fish'. Let him be as rude as he wants, as long as he is there. Stepping back for a moment from the way I approached this issue — which I readily admit was the wrong way to do it, and which I apologize to the community for — and the parties in question, I'm concerned with the general sentiment expressed in this thread. It is quite understandable to be grateful to someone for performing a difficult task; it's another thing to allow that gratitude to mute necessary criticism. I think there's room in our community for both charity *and* civility; if we can improve, we *should* improve. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
XMLField in nfa
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? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
House Wife Hot Sexy Videos In First Night & Aunty's Phone Number
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 u get live web cam sex videos --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 for the middleware we have now to work around that, but > you're also imposing a huge functionality constraint on any future > middleware (all middleware will have to work with the possibility that a > non-consumable generator is there). I don't think that restriction true, and even if it were it wouldn't be a significant change from the present functionality, or your suggested functionality of consuming generators immediately. If someone passes a "non-consumable" generator as content (either to be consumed immediately or by 3rd party middleware), or simply had potentially long running code in their views, the end result is the same. A timeout in the browser. Supporting streaming HttpResponse objects at least gives developers a *chance* to avoid these timeouts. 3rd party middleware can continue to access HttpResponse.content directly and consume generators if they like. There doesn't have to be a requirement that ALL middleware fully support streaming HttpResponse. Clearly some middleware which need to manipulate or access the entire content as a string cannot be streamed. But the core Django middleware shouldn't consume content generators unnecessarily and 3rd party middleware developers should have the *option* of allowing content generators to go unmolested. All that's required is a public attribute on HttpResponse that middleware developers can access if they want to be aware of content generators, to fix code Django middleware to be aware of this where possible and where appropriate, and leave the default as it is - for HttpResponse.content to consume content generators. --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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. If there was no streaming output, why would we accept generators (or anything other than string) as the content to HttpResponse at all? It would be easier to simply require content to be passed in as text and leave it to the developer to consume any generator before instantiating a HttpResponse object. If there was no streaming output, I don't see a good alternative when there's a need to return a large amount of dynamic content (e.g. CSV export) in response to an HTTP request. Even if users were to subclass HttpResponse on their own, won't they run into the same problem with 3rd party middleware (and even standard Django middleware at present) which ignores the fact that generators can be passed to HttpResponse as content? The other alternative I can think of is even less appealing - to trigger some scheduled offline processing through a web request and notify the user when it's ready to download as static media. The streaming HttpResponse functionality was initially favoured by Adrian when Ivan introduced it. It would be a shame to "just say no" to it, now. Is it really so bad to add a public attribute on HttpResponse that indicates whether or not the content is a static string or a generator, and have the Django standard middleware (especially any that are enabled by default) be aware of this and only enable features that require checking the entire content when a generator has not been used. Features such as: generating an ETag header, compressing the entire content in one hit instead of iteratively (is there a significant benefit to doing this in one hit?), and setting the Content-Length header? The default behaviour by "unaware" middleware is still to consume any content generator, so those middleware that are ignorant of streaming response will continue to work as they do now. But 3rd party developers who are aware of this can support it if they chose, or not, and Django should support it as best it can. --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 everybody will have to behave this way. If I > am writing a piece of middleware I have to assume the worst case, which > here means that the content is a non-repeatable generator. Now I understand what you don't like. If we simply make HttpResponse to replace its source generator with a string upon exhaustion, the problem will disappear. But it's another bug. I'm talking here along the lines "why don't we make GzipMiddleware not read response.content if it doesn't have to". > It's not something that cannot wait and be > trialled in various approaches after 1.0 Oh, yes, definitely post-1.0. > The > ticket itself already proposes some things that will lead to bugs: for > example, content-length must *always* be set I was thinking about it myself... But don't things like Comet work with infinitely long responses that don't have content length? --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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. > > Agreed. > > > But the default behaviour shouldn't > > require repetitive practices from normal, everyday middleware. > > What exactly you mean by "repetitive practices"? I'm afraid my English > fails me again, sorry! At the moment, lots of pieces of middleware are buggy because they consume the content from response.content and neither the content property nor the middleware itself puts the content back into the response. Those pieces of middleware should, with the current state of the code, be checking if the response was created from an iterator and, if so, be careful to replace the content after use by poking into the internals of the response. Every single piece of middleware that examines response.content needs to do this (this is the bit that requires the repetition). Of course, that's a silly requirement (and requires poking at non-public pieces of the response). The response should just return a copy of the content when response.content is accessed, which means turning any iterator into a proper string. > > If I write a third-party middleware that behaves exactly as the > > content-length middleware does now, it won't work with something that > > can only be used as a generator. Since I won't know ahead of time what > > responses will be give to this middleware I am therefore forced to > > assume such a generator will be passed in. Thus, a change like this is > > saying that from now on, for all time, no middleware can look at the > > content of the response unless it fits into the very narrow profile in > > that ticket (matching one or other content types, etc). > > If a middleware has to look at the content - it will. But why not make > certain standard middleware not required to look at the content? They > will be more useful then, and it doesn't imply, IMHO, that everyone > should do it. No? But it *does* require that everybody will have to behave this way. If I am writing a piece of middleware I have to assume the worst case, which here means that the content is a non-repeatable generator. Since generators would be permitted in that world, I have to treat them as possible in my middleware code. So I cannot examine the content. Otherwise my middleware is crippled as a reusable piece of code: it would have to carry a big warning saying "cannot be used unless you know your responses will never use generators", which means I have to investigate the details of every third-party app I have installed before I can safely use my middleware. That simply is not going to be good practice. I really don't see that it's worth the enormous complexity it brings at the moment to introduce this. It's not something that cannot wait and be trialled in various approaches after 1.0, but rushing to create some public interface and functionality promises right now so that generators become fully supported in HttpResponse is going to lead to bugs. The ticket itself already proposes some things that will lead to bugs: for example, content-length must *always* be set, since chunked transfer-encoding isn't permitted with WSGI, so it's not a question of checking _is_string or not -- which, btw, is an internal attribute that middleware should never access -- but, rather, a question of whether the header has already been set. 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 practices from normal, everyday middleware. What exactly you mean by "repetitive practices"? I'm afraid my English fails me again, sorry! > If I write a third-party middleware that behaves exactly as the > content-length middleware does now, it won't work with something that > can only be used as a generator. Since I won't know ahead of time what > responses will be give to this middleware I am therefore forced to > assume such a generator will be passed in. Thus, a change like this is > saying that from now on, for all time, no middleware can look at the > content of the response unless it fits into the very narrow profile in > that ticket (matching one or other content types, etc). If a middleware has to look at the content - it will. But why not make certain standard middleware not required to look at the content? They will be more useful then, and it doesn't imply, IMHO, that everyone should do it. No? This got me thinking that the real problem is, in fact, a bit different. Right now middleware applies to all responses indifferently. But it looks like there are at least one more or less common case -- returning a big iterable -- for which most middleware don't make sense anyway and it's better handled as an exception. So may be we should devise a mechanism for such exceptions that won't require a middleware itself to be aware of it. --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 > > non-repeatable consumption. > > Malcolm, sorry, that won't work. I've implemented iterable HttpResponse > in the first place out of purely practical reason: web server times out > if a particularly long file was passed into an HttpResponse. And also it > was really slow and was consuming all the memory. 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. If somebody has particular requirements like yours, then, absolutely, they should use a subclass of HttpResponse that doesn't do that. And they know the restrictions from that decision. But the default behaviour shouldn't require repetitive practices from normal, everyday middleware. > In fact this ticket appeared out of our conversation with Tai Lee. I > don't think you argument on adding complexity makes sense because not > all middleware should care about this. Why, say, TransactionMiddleware > should be affected? Or some 3rd-party HTMLValidationMiddleware which > won't touch huge iterators because it checks only HTML? This patch just > establishes a good practice to follow: if you expect a "reasonably > short" response in your middleware -- check for it. If I write a third-party middleware that behaves exactly as the content-length middleware does now, it won't work with something that can only be used as a generator. Since I won't know ahead of time what responses will be give to this middleware I am therefore forced to assume such a generator will be passed in. Thus, a change like this is saying that from now on, for all time, no middleware can look at the content of the response unless it fits into the very narrow profile in that ticket (matching one or other content types, etc). 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 implemented iterable HttpResponse in the first place out of purely practical reason: web server times out if a particularly long file was passed into an HttpResponse. And also it was really slow and was consuming all the memory. In fact this ticket appeared out of our conversation with Tai Lee. I don't think you argument on adding complexity makes sense because not all middleware should care about this. Why, say, TransactionMiddleware should be affected? Or some 3rd-party HTMLValidationMiddleware which won't touch huge iterators because it checks only HTML? This patch just establishes a good practice to follow: if you expect a "reasonably short" response in your middleware -- check for it. --~--~-~--~~~---~--~~ 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: Community representation, or, #django user "Magus-" needs to go far away
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 bit more polite, but I'd say his > patience and dedication are legend. 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 single most important person in the channel. He has even taken the trouble of writing a script whereby he can generate almost instantaneous references to the *relevant* docs. It is easy to give direct answers - difficult, irritating and time consuming to 'teach to fish'. Let him be as rude as he wants, as long as he is there. > -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/code/ --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 streaming > HttpResponse objects that use a generator to yield content > progressively. > > I'd like to get some feedback on the direction and implementation of > the patch and proposed solution before I go any further with tests or > documentation changes. I don't think we should be supporting on-demand generation like this. Go back a year or 18 months in the archives and look at where Brian Harring put up some patches to do that sort of thing. He and I and others spent ages chasing down unintended side-effects and in the end it was considered not worth it. That was tip-of-the-iceberg stuff. Yes, it's probably possible to get it right, but I'm not convinced it's worth it. 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 for the middleware we have now to work around that, but you're also imposing a huge functionality constraint on any future middleware (all middleware will have to work with the possibility that a non-consumable generator is there). You're also effectively said that only certain content types can be streamed (because a whole bunch of them *will* be affected by consuming middleware). "Just say no" is a cleaner solution here. 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. The only thing that might be worth doing in this are is adding a way to say "middleware should never be called on this response" and then somebody can write their own HttpResponse subclass and be in complete control of their destiny. Adding all the complexity to the existing HttpResponse gets a -1 from me. It's too easy to have unintended side-effects and not really in the sweet spot of Django. It also doesn't seem to be a 1.0 requirement. 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: Community representation, or, #django user "Magus-" needs to go far away
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. Let's not have a flamewar if at > all possible, mmmkay? I think that it's very telling that there have been so few flare ups in the community to date (sadly the change in logger bots has deleted my coining of the word 'Djihad'). Magus- has a never ending supply of patience and for the majority of time puts it to good use. Having run out of time/energy myself trying to help out a little in the early days I think that his efforts should be rewarded. I found things went a lot more smoothly if I pretended he was my German friend. YMMV. Felix --~--~-~--~~~---~--~~ 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: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 a generator to yield content > progressively. > > I'd like to get some feedback on the direction and implementation of > the patch and proposed solution before I go any further with tests or > documentation changes. In GzipMiddleware you don't touch Content-Length if the response is not string. This means that if a response has Content-Length already set it will become incorrect upon gzipping the content. In this case Content-Length can only be deleted from headers, though sending responses with no determined length is a bit ugly... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.
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 content progressively. I'd like to get some feedback on the direction and implementation of the patch and proposed solution before I go any further with tests or documentation changes. Cheers. Tai. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
