Re: Django's CVB - Roadmap?
My feeling is that though some people might have uses for CBV, we shouldn't be suggesting that developers should prefer CBV to function based views. When it comes to maintainability, FBV are better, and I would agree that they are more Pythonic. When I tried to use CBV, I found the inheritance semantics lead to unexpected results when composing mixins. I wanted to spend my time creating web apps and not debugging to figure what 3 lines of glue code I would have to write in the correct overridden method to make CBV work for me in my usecase. At the time I felt of have a list of say context providers would have made more sense than mixins. If people have uses for CBV, they should be available, but advocating that more builtin or contrib views should be made class based is something I would be against personally, unless it really made sense in a specific use case. Albert O'Connor On Tue, Jun 5, 2012 at 2:02 AM, Marc Tamlyn wrote: > There is a plan to do some work on the docs at the djangocon sprints - in > particular trying to get some examples of when you 'could' and when you > 'should not' use the generic CBVs. > > With regards to Zach's point about TDD testing - some of that may simply be > familiarity. I don't know about you but it would have been very difficult > for me to get into successfully TDDing a functional view until I'd written > several dozen views and knew what the pattern is. You can still test the CBV > top to bottom, exactly as you would with a function based view. Yes there > may be some shift to conventions, but that will come with familiarity. > > I think part of the important difference is that when you look at a CBV for > the purposes of unit testing it, you feel very quickly that you should be > testing the individual methods. This is actually really nice and gives a lot > more branch-coverage without rerunning the same 4 database queries every > time for variables which aren't used. Without CBVs a complex view can easily > extend over 50 or so lines, whereas it's more natural to split this up and > test the sections independently with a Class based system. I know in general > we should be 'writing less view code' and pushing the logic elsewhere, but > that depends on what that logic is - for example the view layer needs to > decide whether to return JSON or HTML depending on certain headers in the > request, and that is more easily testable as an overridden render to > response method than as the last 4 lines of a 50 line view. > > Marc > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ. > > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- ><><><>< Albert O'Connor - amjoc...@gmail.com albertoconnor.ca | wildernesslabs.ca | watpy.ca -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
Class Based View are awesome, except the ones which are built in? I agree, as has been suggested, that if you make a really flat class based views like the admin itself, you can gain some benefits, but I still think those benefits are heavily tied to assumptions one can make in a specific problem space. Keeping the ability to create a Class Based View has value, but it is up to to the people who like them to show the rest of us how they can be used with out creating more problems then they solve, and just because they exist doesn't mean they should be used more than they are. Apparently when it comes to generic class based view they should be used less. Albert On Tue, Jun 5, 2012 at 9:14 AM, Donald Stufft wrote: > On Tuesday, June 5, 2012 at 9:05 AM, Albert O'Connor wrote: > > My feeling is that though some people might have uses for CBV, we > shouldn't be suggesting that developers should prefer CBV to function > based views. When it comes to maintainability, FBV are better, and I > would agree that they are more Pythonic. > > When I tried to use CBV, I found the inheritance semantics lead to > unexpected results when composing mixins. I wanted to spend my time > creating web apps and not debugging to figure what 3 lines of glue > code I would have to write in the correct overridden method to make > CBV work for me in my usecase. At the time I felt of have a list of > say context providers would have made more sense than mixins. > > Don't confuse the current Generic Class Based Views with Class Based > Views in general. In almost every case Class Based Views are a net win, > it's the generic views that are often the incorrect choice (as it makes > sense, > if what your view is doing isn't generic, then a Generic view isn't what you > need). > > > If people have uses for CBV, they should be available, but advocating > that more builtin or contrib views should be made class based is > something I would be against personally, unless it really made sense > in a specific use case. > > Albert O'Connor > > On Tue, Jun 5, 2012 at 2:02 AM, Marc Tamlyn wrote: > > There is a plan to do some work on the docs at the djangocon sprints - in > particular trying to get some examples of when you 'could' and when you > 'should not' use the generic CBVs. > > With regards to Zach's point about TDD testing - some of that may simply be > familiarity. I don't know about you but it would have been very difficult > for me to get into successfully TDDing a functional view until I'd written > several dozen views and knew what the pattern is. You can still test the CBV > top to bottom, exactly as you would with a function based view. Yes there > may be some shift to conventions, but that will come with familiarity. > > I think part of the important difference is that when you look at a CBV for > the purposes of unit testing it, you feel very quickly that you should be > testing the individual methods. This is actually really nice and gives a lot > more branch-coverage without rerunning the same 4 database queries every > time for variables which aren't used. Without CBVs a complex view can easily > extend over 50 or so lines, whereas it's more natural to split this up and > test the sections independently with a Class based system. I know in general > we should be 'writing less view code' and pushing the logic elsewhere, but > that depends on what that logic is - for example the view layer needs to > decide whether to return JSON or HTML depending on certain headers in the > request, and that is more easily testable as an overridden render to > response method than as the last 4 lines of a 50 line view. > > Marc > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/VZsGxxTYyoIJ. > > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > > -- > > <><><>< Albert O'Connor - amjoc...@gmail.com > > albertoconnor.ca | wildernesslabs.ca | watpy.ca > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this grou
Re: Django's CVB - Roadmap?
> Both the Built in Generic Class Based Views, and Class Based Views > in general are great. Generic Class Based Views are not awesome when > your view is not generic. My experience is using Generic Class Based Views as an inspiration for ones own Class Based Views lead to a bad user experience, both for myself and apparently other people. I think it is worth highlight in the documentation that Generic Class Based Views are useful, but apparently not how you should write your own. Mixing in your UserMixin with other mixins that do additional query modifications will lead to the writer of code having to create new mixin which either combines both lines of code into one through copying or explicitly calling each mixin, which will itself be additional lines of code. I can see an argument for using CBV to create library views which are expected to both be reused and customized extensively, but those CBV should themselves be flat with a very clear execution model. Using inheritance to override behaviour with the syndication framework works because you only have to look at one class to see what behaviour you are modifying, but it doesn't scale to a any number of mixins, except many for the one your provide in your distinct use case. It should be noted a vast majority of views that developers write which aren't "generic" will never ever be reused and thus probably should be CBV. Albert On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft wrote: > On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote: > > > > On 06/05/2012 08:12 AM, Donald Stufft wrote: > > In order to do this with FBV's i'd either need to modify the existing > FBV to accept > a parameter that says if it should filter by logged in user or not or > copy/paste > the code into a new FBV. > > > Not true, you can also have a function view that returns a > TemplateResponse, and do the same types of tweaks using reusable decorators. > > Maybe in that exact case. You can take the example further and have the same > or another Mixin also handling setting the user field of model instance > (which on > a tangent, is one of the places Generic CBV's can improve imo). So now you > can > Mixin automatically setting the ``user`` field of a Model to the currently > logged in user. > > You could also be calling an external API, and want to pass additional data > to that > API in this instance of the view, TemplateResponse won't help you and the > original > options stand here where you either copy/paste the view, or modify the > existing > view. > > It's pretty much a fact that module level functions in Python are completely > unable > to deal with any modification to internal logic without building up a list > of kwargs/flags > that they accept. Even if you are forward thinking and break your FBV's into > multiple > sub functions that the actual view calls, you cannot modify how it calls > those functions, > or swap out which functions it calls without getting into hacky monkey > patching or copy > and pasting things. > > > Carl > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- ><><><>< Albert O'Connor - amjoc...@gmail.com albertoconnor.ca | wildernesslabs.ca | watpy.ca -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's CVB - Roadmap?
I did mean shouldn't, sorry about that. We seem to have agreement that when it comes to mixins and the depth of the inheritance hierarchy it easy to go astray, or at least generic CBV did. From that I would argue it is difficult to write a good mixin. I disagree with your digestion line of thinking, because for me the beauty of Django lies in being able to quickly and explicitly answer the question what is this view passing into my template. I think that is more important than knowing what happens when I post to a view versus get it, which I think is still pretty obvious with FBV. As far as I can tell CBV makes the latter more explicit while obscuring the former. It maybe the case that testing is easier with CBV, but I would argue that debugging FBV is easier. You can also add overhead by inheriting from an obscure class based view and only implementing post. From glance a reader won't know what the get does. I can imagine use cases exist where CBV make sense, but they seem to be instances where customization and testing are critical which points me back to library views explicitly meant for reuse, not every day business logic heavy views. Albert On Tue, Jun 5, 2012 at 11:33 AM, Donald Stufft wrote: > > On Tuesday, June 5, 2012 at 11:11 AM, Albert O'Connor wrote: > > Both the Built in Generic Class Based Views, and Class Based Views > in general are great. Generic Class Based Views are not awesome when > your view is not generic. > > > My experience is using Generic Class Based Views as an inspiration for > ones own Class Based Views lead to a bad user experience, both for > myself and apparently other people. I think it is worth highlight in > the documentation that Generic Class Based Views are useful, but > apparently not how you should write your own. > > The GCBV's tried to go very far into reusability, to the point where they > have several layers of indirection to what is going on. Personally I prefer > a case where you have the base view which is well written and contains > all of the "Base" functionality instead of having a base view which > is actually comprised of half 3-6 different Mixins. > > However adopting some of their conventions into your own CBV's will > go a long way (get_object, get_queryset etc). > > > Mixing in your UserMixin with other mixins that do additional query > modifications will lead to the writer of code having to create new > mixin which either combines both lines of code into one through > copying or explicitly calling each mixin, which will itself be > additional lines of code. > > This is only true if you write poor mixins. > > > I can see an argument for using CBV to create library views which are > expected to both be reused and customized extensively, but those CBV > should themselves be flat with a very clear execution model. Using > inheritance to override behaviour with the syndication framework works > because you only have to look at one class to see what behaviour you > are modifying, but it doesn't scale to a any number of mixins, except > many for the one your provide in your distinct use case. > > It should be noted a vast majority of views that developers write > which aren't "generic" will never ever be reused and thus probably > should be CBV. > > I assume you meant shouldn't be here. There are benefits beyond > the reusability (which the reusability is something I speak a lot about), > in terms of testing, breaking things into easier to digest chunks. Even > the most non-generic view tends to create a good deal of boilerplate. > > Even something as simple as the default get() and post() methods > reduces the amount go cognitive overhead needed while parsing > what a view does. > > As an example a dummy: https://gist.github.com/2875669 > > Similar number of lines (intact the CBV is a bit more), however with > the CBV I've broken my view down into smaller chunks which, other > then via self, are not able to affect one another. This allows me to focus > on a much smaller unit of code if I am debugging making me have to > "page" less of the application into my head at once. (As an example, > maybe the post method accidentally reuses a variable from the setup > code that the generic code was expecting to be there). > > Even if all you use the CBV's for is a "Namespace to hold crap" I feel > that your code will end up better as it enables you to break apart a view > into smaller and more manageable chunks, without polluting the views.py > namespace with multiple functions for every view. > > Albert > > On Tue, Jun 5, 2012 at 10:46 AM, Donald Stufft > wrote: > > On Tuesday, June 5, 2012 at 10:35 AM, Carl Meyer wrote: > > > > On
Re: Changes to django's settings module
Hey Omar, Though it may be clear now from this experience, I feel your expectations about how code becomes a part of Django were incorrect, leading to some frustration. The onus is on the contributor not the core committers for nearly all aspects of making a contribution, which is likely a difference versus a smaller open source project. The onus is on the contributor to write the patch, the tests and the documentation. Not having enough time isn't really a reason not too, no one is paid to develop Django and no one has much time. Just sharing code that might be useful is a nice gesture, but one should not expect it to be picked up automatically. The onus is also on the contributor to convince people that the change is worth while. It isn't the job of the core team to argue why a change is not worth making, though they often attempt to do so. The default reaction to change is a conservative one, change must prove why it is useful, not the other way around. Like any open source project Django relies heavily on all the people who contribute, but in order to make it stable and useful to the huge community who uses, the process of getting change into it is intentionally somewhat of an up hill battle where the onus is on the contributor at every stage, not the project maintainers. Albert O'Connor On Sun, Mar 24, 2013 at 7:10 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Sun, Mar 24, 2013 at 6:28 PM, Omer Katz wrote: > >> You are contradicting yourself. At first you said that it does make the >> code clearer. Now you say it doesn't. >> > > My apologies -- I've apparently used an English idiom that doesn't have an > obvious meaning. > > When I said "I'd argue the point that it makes the code clearer", that > means "You said it was clearer, I disagree, and I'd be willing to defend my > position." > > I do not believe that your proposed patch makes the code clearer. > > Ok, you guys are right. I'm adding a new feature. >> If you think my new design isn't good enough do tell me why. I'll improve >> it/change it completely. >> It now doesn't violate SRP, it allows flexability for those who need it >> and maintains backward competitability. What else is missing here? >> I feel a bit like a broken record here because I did specify over and >> over what's the purpose of this change. >> I don't want to load settings from a class.* I'd like to provide >> extensibiloty points in order to help implemet other workflows that people >> use.* >> > > And at this point, I'm also feeling like a broken record. The point that > I, and several other people have made repeatedly is that we fail to see how > these extensibility points would be used in practice. You haven't > demonstrated a use case where what you describe would be helpful. > > Saying "It makes it easier to implement django-configurations" isn't a use > case. A use case here might be "it makes it easier to define the > development/production settings split". > > The purpose of this patch is to: >> >>- Allow developers to implement different workflows for loading >>settings for different environments (class based settings, different >>modules, different packages). >>- Allow developers to load settings from other sources like >>django-debian <https://launchpad.net/django-debian> does. >>- Allow developers to change settings as they are collected (for >>example django-harness >> <https://bitbucket.org/neithere/django-harness>does multiple things like >> this). >> >> There are usecases, some people actually implemented those outside of the >> framework and I don't see a reason why they should. We're perfectionists >> with deadlines right? There's no reason to write django-configurations if >> in five minutes you can get the same result out of the box. >> Do you see value in django-configurations, django-debian or >> django-harness? >> > > In short? No. > > Adding an extensibility point is only beneficial if you actually want that > particular axis to be extensible. It's good that Django has an > extensibility point for database backends -- that allows someone outside > core to develop a backend for DB2 or MSSQL. > > However, I don't see the benefit in having an extensible mechanism for > defining settings. Settings are settings. There should be *one* way to > define them, and that's it. There's *benefit* in there only being one way > to define settings, because that means that someone coming to a project for > doesn't need to discover,
Re: Featurereuqest: Helpfull tracebacks
On Wed, Aug 21, 2013 at 7:55 AM, Florian Apolloner wrote: > > > On Wednesday, August 21, 2013 12:18:24 PM UTC+2, Anssi Kääriäinen wrote: >> >> Improvements to error messages are usually accepted. This idea, too, if >> there is a way to actually do it without ugly hacks. >> > > I doubt there is a way to get that from the error message itself and I'll > strongly object to adding logic like parsing the error message to figure > that stuff out. Especially since the traceback is pretty clear and it's not > as if one were searching through 5000 fields in a model… Also, this error > is the result of putting data into the database without prior validation > which is a bad idea anyways… > Annoyingly it is possible to get this error after passing validation. You can combine Postgres misconfigured not to be UTF-8 with UTF-8 strings with multibyte characters where the validation passes because the string 100 letters or less but the database won't be able to fit the 101 bytes into the column. It is easy to say don't misconfigure Postgres, but it can happen even when you validate correctly. The message is rather vague and could be more helpful, but not if it requires hacks. You can look into the values of variables in the rather long stacktrace to figure out what is happening. Albert > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- ><><><>< Albert O'Connor - amjoc...@gmail.com albertoconnor.ca | watpy.ca | go-opendata.ca -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
Re: Working towards a simpler GCBV implementation?
+1 to anything which makes CBV easier to use and simpler to understand. >From looking at what have done you have been able to address my biggest concern, the depth of the hierarchy. I find using flat "CBV" like the syndication framework a lot easier then the current GCBV implementation. Thanks, Albert O'Connor On Sat, Oct 5, 2013 at 7:27 AM, Tino de Bruijn wrote: > > On Thu, Oct 3, 2013 at 11:09 AM, Tom Christie wrote: > >> * If a simpler GCBV implementation along the lines of >> django-vanilla-views is something we think we should working towards. >> > > Hells yes, +1. I love CBV, but when it gets a little more complex, I get > dazzled. > > >> * What approaches we might be able to take to dealing with backwards >> compatibility if we did want to do so. >> > > Hmm, from django.new_views import ..., like was done with new_forms? > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CANQFsQCg7zVkjvRM4M6MdvhtmkBMqyp-FhAr12yjFF57nJY0Yw%40mail.gmail.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- ><><><>< Albert O'Connor - amjoc...@gmail.com albertoconnor.ca | watpy.ca | go-opendata.ca -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMAY443M_37u_6sQK%2BFB5abCFCJYVWhFa6r4QO550b%2B7e5bMiQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: DEPs: Django Enhancement Proposals
+1 On Mon, Apr 14, 2014 at 3:39 PM, Alex Gaynor wrote: > The same way we do now? > > > On Mon, Apr 14, 2014 at 3:34 PM, Andrew Farrell wrote: > >> Who is responsible then for deciding what the conclusion of the >> discussion was? If there is no such person, how does the process handle the >> case when people talk past each other and don't actually come to a >> conclusion? >> >> >> On Mon, Apr 14, 2014 at 2:22 PM, Michael Manfre wrote: >> >>> I think there would be value in adding DEPs for the major features that >>> will ship with 1.7. >>> >>> Regards, >>> Michael Manfre >>> >>> >>> >>> >>> On Mon, Apr 14, 2014 at 2:17 PM, Aymeric Augustin < >>> aymeric.augus...@polytechnique.org> wrote: >>> >>>> On 14 avr. 2014, at 19:51, Adrian Holovaty wrote: >>>> >>>> > One idea was to start doing a Django equivalent of Python's PEPs, >>>> which would serve as a formal way to document large new features/changes in >>>> Django. >>>> >>>> Would it be interesting to retro-spec the major features added in the >>>> past? >>>> >>>> -- >>>> Aymeric. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-developers+unsubscr...@googlegroups.com. >>>> To post to this group, send email to django-developers@googlegroups.com >>>> . >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/58B4EA9B-C450-476D-A9E9-8008718FF912%40polytechnique.org >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-developers+unsubscr...@googlegroups.com. >>> To post to this group, send email to django-developers@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAGdCwBv7qvwv8Ksdajz1UUWgYcXEt%3DPLHfZCRjGW0YjT_TW51Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at http://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CA%2By5TLa1o9PO4yNAt_7EELaU4H9MoXH-3DuVObKKW%3DjYopizyA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFRnB2VVbvarWOWa4BGKqNFn_EFz%2BntyTqp
