Re: Why passing request, *args, **kwargs in dispatch method for generic views

On Friday, 23 October 2015 19:31:07 UTC+5:30, Marc Tamlyn wrote: > > This would cause too much churn for user code - there are millions of CBVs > in the wild with customised dispatch/get/post/etc methods which expect > these variables and perhaps use them directly. Unfortunately this ship has

Re: Why passing request, *args, **kwargs in dispatch method for generic views

This would cause too much churn for user code - there are millions of CBVs in the wild with customised dispatch/get/post/etc methods which expect these variables and perhaps use them directly. Unfortunately this ship has sailed. On 23 October 2015 at 14:45, Tom Christie wrote: > Although those v

Re: Why passing request, *args, **kwargs in dispatch method for generic views

Although those variables are available in both places I'd prefer to see them passed explicitly. That will tend to nudge users slightly more towards passing variable around explicitly and slightly away from storing state on the view instance (which can be a bit of a gnarly practice - harder to fo

Re: Why passing request, *args, **kwargs in dispatch method for generic views

It looks like setting the request/args/kwargs attributes came after the original CBGV implementation. https://github.com/django/django/commit/ea6b95db https://code.djangoproject.com/ticket/19316 https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion I haven't looked closely

Why passing request, *args, **kwargs in dispatch method for generic views

Hello all, With reference to this line: https://github.com/django/django/blob/master/django/views/generic/base.py#L61 from django.view.generic.base before calling self.dispatch request, args and kwargs attributes have been added to self. So these all are available in self in http_method handle

Re: Generic forms (ModelForm) provide HTML for a form! Can generic views (DetailView) do same?

The problem with bootstrapping code like this is that it's great for a super simple project, but you instantly want to customise it for any project of any serious scope. It seems to me a perfect candidate for a simple external project, although you may wish to have a different API so it's more reu

Generic forms (ModelForm) provide HTML for a form! Can generic views (DetailView) do same?

I asked this question on the user group and got no reply fast, so I just wrote a derived class to do it quickly: https://groups.google.com/d/msg/django-users/n87bFh8IYYc/MhkNmVBDAwAJ it's a hack and not what I'd call a patch, but one user liked it and asked that I seek it's inclusion in Django.

Re: Confusion around generic views queryset cloning.

On 22 July 2013 10:37, Loic Bistuer wrote: > I updated the PR to do away with the public `clone()` method. > > As long as we have a long-term goal for a `QuerySet.clone()` method, I'm > happy. > > If we plan on changing the cloning behavior, now is effectively a bad time > to introduce it. > No

Re: Confusion around generic views queryset cloning.

I updated the PR to do away with the public `clone()` method. As long as we have a long-term goal for a `QuerySet.clone()` method, I'm happy. If we plan on changing the cloning behavior, now is effectively a bad time to introduce it. -- Loic On Jul 22, 2013, at 2:45 PM, Anssi Kääriäinen wrot

Re: Confusion around generic views queryset cloning.

On Sunday, July 21, 2013 9:53:36 PM UTC+3, Loic Bistuer wrote: > > Explicit is better than implicit and `all()` is more a `Manager` concept > than a `QuerySet` one. > > IMO `QuerySet.all()` should only be used when API parity with `Manager` is > needed. > > Internally `QuerySet` uses `_clone()`

Re: Confusion around generic views queryset cloning.

Explicit is better than implicit and `all()` is more a `Manager` concept than a `QuerySet` one. IMO `QuerySet.all()` should only be used when API parity with `Manager` is needed. Internally `QuerySet` uses `_clone()` rather than `all()` and with #20625 on its way, I think it's useful to have a

Re: Confusion around generic views queryset cloning.

Can't we just use .all() in views instead of creating a new QuerySet method which does exactly the same thing? On Sun, Jul 21, 2013 at 12:34 PM, Loic Bistuer wrote: > My attempt with a public `QuerySet.clone()` method and docs for > `*ObjectMixin.queryset`: > > https://github.com/django/django/p

Re: Confusion around generic views queryset cloning.

My attempt with a public `QuerySet.clone()` method and docs for `*ObjectMixin.queryset`: https://github.com/django/django/pull/1384 Made a PR to facilitate review and discussion, feel free to close if you think it's the wrong approach. -- Loic -- You received this message because you are su

Re: Confusion around generic views queryset cloning.

Thanks both, the responses are very much appreciated. > It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an empty

Re: Confusion around generic views queryset cloning.

I don't think this should need documenting explicitly. It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an empty list

Re: Confusion around generic views queryset cloning.

Hi Tom, (You said in a follow-up this was intended for django-users, but personally I think it's on-topic for -developers, so I'm replying here.) On 07/11/2013 02:54 PM, Tom Christie wrote: > I've noted that the generic view implementations use the private > `_clone` method when returning the que

Re: Confusion around generic views queryset cloning.

My apologies, this was intended to be posted to the Django users group. On Thursday, 11 July 2013 21:54:25 UTC+1, Tom Christie wrote: > > I've noted that the generic view implementations use the private `_clone` > method when returning the queryset > attribute

Confusion around generic views queryset cloning.

I've noted that the generic view implementations use the private `_clone` method when returning the queryset attribute . Presumably the need for that is something to do with the potential for querysets to be cached

Re: Problems with date-based generic views when USE_TZ=True

On 28 avr. 2012, at 07:56, Mike Yumatov wrote: >> They are in local time in the default time zone. > Are you sure? Because if so, YearArchiveView is broken: it uses year lookup > (https://docs.djangoproject.com/en/1.4/ref/models/querysets/#year), which is > performed in UTC. Indeed, you're rig

Re: Problems with date-based generic views when USE_TZ=True

Hi Aymeric, On Friday, April 27, 2012 at 9:21 PM, Aymeric Augustin wrote: > > After some research, I understand that there are more problems with this > > views, than I thought at first. django.views.generic.dates module uses > > aware and naive datetime objects together, which breaks all date-

Re: Problems with date-based generic views when USE_TZ=True

Hi Mike, On 27 avr. 2012, at 14:51, Mike Yumatov wrote: > I wrote a ticket about time zone warnings in date-based generic views: > https://code.djangoproject.com/ticket/18217 It isn't necessary to notify django-developers when you create a ticket; that's the job of django-u

Problems with date-based generic views when USE_TZ=True

Hi! I wrote a ticket about time zone warnings in date-based generic views: https://code.djangoproject.com/ticket/18217 After some research, I understand that there are more problems with this views, than I thought at first. django.views.generic.dates module uses aware and naive datetime

Re: Generic edit generic views don't create `fail_silently` messages anymore.

it this feature for class based equivalents? > > If it was deliberately omitted then, since function based views are > deprecated, the message framework documentation for the `fail_silently` kwarg > should be updated to remove the part where it makes reference to generic > view

Generic edit generic views don't create `fail_silently` messages anymore.

mitted then, since function based views are deprecated, the message framework documentation for the `fail_silently` kwarg should be updated to remove the part where it makes reference to generic views using it internally<https://docs.djangoproject.com/en/dev/ref/contrib/messages/#s-failing-sile

Re: AJAX generic views

On 03-02-12 09:43, gert wrote: I've been using the class based views from day one and loving it! It would be great if there was a generic view to bring some consistency to the way everybody implements AJAX. Or if not a view then maybe a mixin or two (JSONResponseMixin used in the documentation

Re: AJAX generic views

I am also interested in where this is going. I have written simple extensions of BaseDetailView similar to the approach taken in the "HybridDetailView" example in the documentation (https:// docs.djangoproject.com/en/1.3/topics/class-based-views/#more-than-just- html). Would love to hear other id

AJAX generic views

Hi I've been using the class based views from day one and loving it! It would be great if there was a generic view to bring some consistency to the way everybody implements AJAX. Or if not a view then maybe a mixin or two (JSONResponseMixin used in the documentation comes to mind). Any thoughts

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

On Thu, Dec 9, 2010 at 17:10, Florian Apolloner wrote: > +1 on fixing the the verbose_name_plural usage, as __every__ user with an > activated language (that is: aside from english) will run into it. Regarding > the double entry in the context: I am +1 on leaving object_list in there. > This way m

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

+1 on fixing the the verbose_name_plural usage, as __every__ user with an activated language (that is: aside from english) will run into it. Regarding the double entry in the context: I am +1 on leaving object_list in there. This way middlewares (or other generic view mixins) could act on object_li

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

the ticket http://code.djangoproject.com/ticket/14878 -- Diego Andrés Sanabria Ingeniería de Sistemas Universidad Distrital about:me http://www.google.com/profiles/diegueus9 cel 3015290609 2010/12/9 Łukasz Rekucki > On 9 December 2010 19:40, Gert Va

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

On 9 December 2010 19:40, Gert Van Gool wrote: > BTW: what happens when your verbose_name_plural contains a quote (single or > double)? > -- Gert Or whitespace :) Plus, most people put a ugettext_lazy there, so it's translated in admin model list. I don't think context variable names shouldn't de

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

'paginator': None, 'page_obj': None, 'is_paginated': False, 'object_list': queryset <- here } context.update(kwargs) context_object_name = self.get_co

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

BTW: what happens when your verbose_name_plural contains a quote (single or double)? -- Gert Mobile: +32 498725202 Twitter: @gvangool Web: http://gert.selentic.net On Thu, Dec 9, 2010 at 18:42, Luke Plant wrote: > Hi, > > First, in answer to your question in the

Re: Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

Hi, First, in answer to your question in the title - yes, normally you should report bugs like this to Trac, once you are sure you've found a bug. > The problem here is: > > > If i don't set a context_object_name in my app, the method > get_context_object_name puts a name based in the verbose_

Should i report this like bugs in TRAC? Generic Views issue? django.13 alpha and svn

Hello, I just found what I think is a couple of bugs in Generic Views: First: in the class MultipleObjectMixin, in the file django/views/generic/list.py there is a couple of methods that i think have a possible bug or missbehavior: lines 65/101 def get_context_object_name(self

Re: #6735 -- Class based generic views: call for comment

1) Test coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can spec

Re: #6735 -- Class based generic views: call for comment

On Wed, Oct 6, 2010 at 8:33 AM, Luke Plant wrote: > On Tue, 2010-10-05 at 22:29 +0100, I wrote: > >> Russell - beware - I think bitbucket has managed to create a very broken >> clone. I did a fork as well, and both of our repositories are missing >> thousands of commits.  I can do a pull from djan

Re: #6735 -- Class based generic views: call for comment

but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can specify a model and the form is optional. Ben On 5 Oct 2010, at 15:43, Jacob Kaplan-Moss wrote: > On Tue,

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 22:29 +0100, I wrote: > Russell - beware - I think bitbucket has managed to create a very broken > clone. I did a fork as well, and both of our repositories are missing > thousands of commits. I can do a pull from django/django and I then get > a complete repository which th

Re: #6735 -- Class based generic views: call for comment

t coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can specify a m

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 21:03 +0800, Russell Keith-Magee wrote: > Ok - so to kick the process into the next phase, I've just created a > Django branch in my bitbucket repo [1] to cover introducing this to > trunk. Russell - beware - I think bitbucket has managed to create a very broken clone. I did

Re: #6735 -- Class based generic views: call for comment

On Oct 5, 10:43 am, Jacob Kaplan-Moss wrote: > >  * Does django.views.generic.utils.coerce_put_post() indicate a change > > that needs to be made in Django? (Is there an existing ticket for > > this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't > really "get" PUT very we

Re: #6735 -- Class based generic views: call for comment

On 5 October 2010 22:10, David Larlet wrote: > > > Jacob Kaplan-Moss a écrit : >> >> On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee >>  wrote: >>> >>>  * Are there any outstanding tickets on generic views that will be >>> closed by merg

Re: #6735 -- Class based generic views: call for comment

Jacob Kaplan-Moss a écrit : On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee wrote: * Are there any outstanding tickets on generic views that will be closed by merging this branch, and do they ask for any features that aren't fixed by this branch? Almost certainly yes :) We

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 1:04 pm, Andrew Godwin wrote: > On 04/10/10 17:28, legutierr wrote: > > >    * First, treat data processing and retrieval as separable from > > rendering.  Create a bright line of separation between the two > > conceptual elements of the view (data and rendering), and do it early > > on,

Re: #6735 -- Class based generic views: call for comment

On Tue, 2010-10-05 at 09:43 -0500, Jacob Kaplan-Moss wrote: > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the admindocs

Re: #6735 -- Class based generic views: call for comment

On 2010-10-01, at 3:57 PM, David P. Novakovic wrote: > I may be missing something obvious here, so please tell me if I am.. > but couldn't the resolver just check that quacks like something > OOViewish has been passed in and simply branch and init the class > before calling the view in the same way

Re: #6735 -- Class based generic views: call for comment

ne that I'd like to hit, and then a longer bug-fix period we can use to clean up PUT/POST and such. >  * Are there any outstanding tickets on generic views that will be > closed by merging this branch, and do they ask for any features that > aren't fixed by this branch? Almost cert

Re: #6735 -- Class based generic views: call for comment

ase, I've just created a Django branch in my bitbucket repo [1] to cover introducing this to trunk. I've used the implementation in Ben's github repo [2] as a starting point -- it looks like David Larlet has already made the changes to implement the classmethod2 approach. So far, other

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 3:16 AM, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > >> Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor > arguments to it: > > url(r

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:43 AM, George Sakkis wrote: > On Oct 4, 10:55 pm, "David P. Novakovic" > wrote: >> On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis >> wrote: >> >> > Since dispatch is going to be defined on the base View class, can't we >> > omit it from the urlconf and have the URLresolv

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 10:55 pm, "David P. Novakovic" wrote: > On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > > Since dispatch is going to be defined on the base View class, can't we > > omit it from the urlconf and have the URLresolver do: > > >  if isinstance(view, type) and issubclass(view, View)

Re: #6735 -- Class based generic views: call for comment

I agree with George, and would like to not have to write the dispatch out every time, but my only concern is how confusing an implicit dispatch would be for developers first using the new class-based Views system. As long as it was made abundantly clear via the docs what exactly is happening when y

Re: #6735 -- Class based generic views: call for comment

On Tue, Oct 5, 2010 at 5:21 AM, George Sakkis wrote: > > Since dispatch is going to be defined on the base View class, can't we > omit it from the urlconf and have the URLresolver do: > >  if isinstance(view, type) and issubclass(view, View): >      view = view.dispatch Russ mentioned this one ca

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 9:16 pm, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > > Last idea, I swear, > > I didn't swear, so here is another slight variation :-) You actually > *call* the classmethod in your URLconf, passing any constructor > arguments to it: > > url(r'^detail/auth

Re: #6735 -- Class based generic views: call for comment

On Oct 4, 7:22 pm, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > > Given that the primary complain against the __new__ solution is that > > it's unintuitive to Python programmers that instantiating their class > > results in some other class, why not simply go

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Last idea, I swear, I didn't swear, so here is another slight variation :-) You actually *call* the classmethod in your URLconf, passing any constructor arguments to it: url(r'^detail/author/(?P\d+)/$', views.AuthorDetail.as_view(so

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 20:03, Luke Plant wrote: > On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >> results in some other class, why not simply go with

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 19:44, Luke Plant wrote: > On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote: > >> The only problem is decorators: You can't just simply apply >> login_required() to the class or the dispatch() method.  Otherwise, I >> like this approach. > > It works fine: > > http://bitbu

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used as:

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 19:37 +0200, Łukasz Rekucki wrote: > The only problem is decorators: You can't just simply apply > login_required() to the class or the dispatch() method. Otherwise, I > like this approach. It works fine: http://bitbucket.org/spookylukey/django-class-views-experiments/src/

Re: #6735 -- Class based generic views: call for comment

On 4 October 2010 19:22, Jacob Kaplan-Moss wrote: > On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: >> Given that the primary complain against the __new__ solution is that >> it's unintuitive to Python programmers that instantiating their class >> results in some other class, why not simply g

Re: #6735 -- Class based generic views: call for comment

On Mon, 2010-10-04 at 13:08 -0400, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod. Simply used as:

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 12:08 PM, Alex Gaynor wrote: > Given that the primary complain against the __new__ solution is that > it's unintuitive to Python programmers that instantiating their class > results in some other class, why not simply go with a more explicit > classmethod.  Simply used as: >

Re: #6735 -- Class based generic views: call for comment

On Mon, Oct 4, 2010 at 1:04 PM, Andrew Godwin wrote: > On 04/10/10 17:28, legutierr wrote: >> >>   * First, treat data processing and retrieval as separable from >> rendering.  Create a bright line of separation between the two >> conceptual elements of the view (data and rendering), and do it ear

Re: #6735 -- Class based generic views: call for comment

On 04/10/10 17:28, legutierr wrote: * First, treat data processing and retrieval as separable from rendering. Create a bright line of separation between the two conceptual elements of the view (data and rendering), and do it early on, at a high level, inside dispatch(). Instead of expecting

Re: #6735 -- Class based generic views: call for comment

ing's @render_to and @ajax_request decorators, and would have classy views return dictionaries instead of HTTPResponse objects. Of course, users could subclass the base View class to do any of these things, but then they would be discarding most of this module's useful functionality

Re: #6735 -- Class based generic views: call for comment

> > On Mon, Oct 4, 2010 at 8:08 AM, Andrew Godwin wrote: > > I'd just like to add more noise to the signal and reiterate this - storing > state on self (or request) leads to much cleaner, less fragile, more > subclassable views (in my own experience, having written both a

Re: #6735 -- Class based generic views: call for comment

more subclassable views (in my own experience, having written both a set of generic views with and without state like this). I personally think self is the place to store this state (since, as Russ keeps saying, that's how nearly all Python classes do it), but storing it on request isn't to

Re: #6735 -- Class based generic views: call for comment

I should add.. The bonus of using class-based decorators is that decorated views can be subclassed. All other functionality is retained. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 1:02 pm, Russell Keith-Magee wrote: > On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > > wrote: > > While I'm in the "one singleton view instance is best" camp and think > > that storing some state on the request and some on

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 1:02 pm, Russell Keith-Magee wrote: > On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > > wrote: > > While I'm in the "one singleton view instance is best" camp and think > > that storing some state on the request and some on

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 8:02 PM, Russell Keith-Magee wrote: >> Other frameworks seem have View/Handler instances per request, such as >> appengine's webapp so there is some precedent for creating an instance >> per request. >> >> http://code.google.com/appengine/docs/python/gettingstarted/handlingf

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 3 October 2010 06:12, Ian Lewis wrote: >> Flask seems to do it the callable singleton way: >> >> http://flask.pocoo.org/docs/patterns/lazyloading/ >> > I never used Flask, so I might be missing something, but I don't see a > singleton view instance here - just a pro

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 4:20 am, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > >> We could even wrap the "no args to __init__" error check in a method > >> that enables it to be overridden and silenced in a subclass; that way, > >> introducing the potentially un-threadsafe be

Re: #6735 -- Class based generic views: call for comment

On Oct 3, 6:12 am, Ian Lewis wrote: > Other frameworks seem have View/Handler instances per request, such as > appengine's webapp so there is some precedent for creating an instance > per request. > > http://code.google.com/appengine/docs/python/gettingstarted/handlingf... > > Flask seems to do i

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 12:12 PM, Ian Lewis wrote: > On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee > wrote: > While I'm in the "one singleton view instance is best" camp and think > that storing some state on the request and some on the view is a bit > gross, I understand Russell's argument

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 3 October 2010 04:44, Russell Keith-Magee wrote: >> 2010/10/3 Łukasz Rekucki : > def with_args(view_cls, **kwargs): >    return type(view_cls.__name__, (view_cls,), kwargs) > > # in urls.py: > >  (r'^somepath', with_args(MyView, option=False

Re: #6735 -- Class based generic views: call for comment

Hi, first of all, I'd like to say that I fully agree that the final solution has to be thread-safe and has to support storing state on self. On Oct 2, 12:32 pm, Russell Keith-Magee wrote: > 2010/10/2 Łukasz Rekucki : > > Now you lost me. If we are discouraging people from using arguments to > > _

Re: #6735 -- Class based generic views: call for comment

On 3 October 2010 06:12, Ian Lewis wrote: > Flask seems to do it the callable singleton way: > > http://flask.pocoo.org/docs/patterns/lazyloading/ > I never used Flask, so I might be missing something, but I don't see a singleton view instance here - just a proxy, that imports a function on first

Re: #6735 -- Class based generic views: call for comment

On 3 October 2010 04:44, Russell Keith-Magee wrote: > 2010/10/3 Łukasz Rekucki : >> On 2 October 2010 12:32, Russell Keith-Magee wrote: >>> 2010/10/2 Łukasz Rekucki : On 2 October 2010 10:34, Russell Keith-Magee wrote: > >>   3) How do we make this shared settings immutable between re

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 11:20 AM, Russell Keith-Magee wrote: >> The issue is not only the frequency of failure, but how explicit/clear >> it is. The failure here is so obscure and difficult to track down, it >> is likely to generate an outsize support burden. In contrast, raising >> an error on ass

Re: #6735 -- Class based generic views: call for comment

Sorry, I keep top replying in my emails. It's because I'm mostly taking everything in and not really replying to anyone specifically. I _really_ like the idea of View being synonymous with a ResponseFactory. Using __call__: The view base class can take *args and **kwargs and apply them lazily wh

Re: #6735 -- Class based generic views: call for comment

2010/10/3 Łukasz Rekucki : > On 2 October 2010 12:32, Russell Keith-Magee wrote: >> 2010/10/2 Łukasz Rekucki : >>> On 2 October 2010 10:34, Russell Keith-Magee >>> wrote: > To sum this up, I think the important questions are: > >   1) Do View instances need to share anything ? I say: yes. Agree

Re: #6735 -- Class based generic views: call for comment

On Sun, Oct 3, 2010 at 12:20 AM, George Sakkis wrote: > On Oct 1, 7:26 am, Russell Keith-Magee > wrote: >> >> I've just added a summary of the last thread on class-based views [1]. > > Thanks for writing this up. Having missed the discussion on that > thread, the summary saved me a whole lot of t

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 8:01 PM, Carl Meyer wrote: > > > On Oct 2, 4:34 am, Russell Keith-Magee > wrote: >> I can't argue with the fact that setting variables in __init__() is a >> common idiom in Python generally, and this is certainly a weakness of >> copy on call that will fail in non-thread sa

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:40 PM, Russell Keith-Magee wrote: > On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote: >> Classes that represent real objects have state. Like cars have color, >> make and registration number, your models have attributes that >> differentiate them from other objects o

Re: #6735 -- Class based generic views: call for comment

On 2 October 2010 12:32, Russell Keith-Magee wrote: > 2010/10/2 Łukasz Rekucki : >> On 2 October 2010 10:34, Russell Keith-Magee wrote: >>> >>> Another option would be to use copy-on-call, but raise an error if >>> they provide any arguments to __init__(). This would be annoying and >>> counter t

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 6:46 pm, Luke Plant wrote: > On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote: > > Having said that, I'm in favour of the first approach mentioned in the > > wiki (store state on request) and I'm surprised it doesn't seem to > > have any traction in this thread. The only argument a

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 1:01 pm, Carl Meyer wrote: > Again, arguments to __init__ are not the issue. What would have to be > checked is any assignment to self that takes place in __init__. How do > you propose to check that? > I think __slots__ would do for this: it would prevent a user of a view instance fr

Re: #6735 -- Class based generic views: call for comment

On Sat, 2010-10-02 at 09:20 -0700, George Sakkis wrote: > Having said that, I'm in favour of the first approach mentioned in the > wiki (store state on request) and I'm surprised it doesn't seem to > have any traction in this thread. The only argument against is "it's > unusual to have a class whe

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 7:26 am, Russell Keith-Magee wrote: > > I've just added a summary of the last thread on class-based views [1]. Thanks for writing this up. Having missed the discussion on that thread, the summary saved me a whole lot of time. > I'd like to try and get this in for 1.3. It's a big featur

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 12:32 pm, Russell Keith-Magee wrote: > > The difference is that __new__ doesn't *ever* allow for initialization > arguments -- there is no way to pass an argument in. An "arguments > disabled by default" __init__+copy implementation allows arguments as > an opt-in. > > There's also the

Re: #6735 -- Class based generic views: call for comment

On Fri, 2010-10-01 at 17:31 +0100, Luke Plant wrote: > Or, more drastically, we could just do this: > > class View(object): > def __call__(self, request, *args, **kwargs): > self.request = request > self.args = args > self.kwargs = kwargs > resp = self.dispatch(

Re: #6735 -- Class based generic views: call for comment

I've been keeping up with this thread but have not had the time to respond until now. I will endeavor to keep it brief as this thread has grown quite long! +1 on using a single dispatch() method rather than hard-coding HTTP method dispatch. As was pointed out, there are many possible dispatch patt

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 4:34 am, Russell Keith-Magee wrote: > I can't argue with the fact that setting variables in __init__() is a > common idiom in Python generally, and this is certainly a weakness of > copy on call that will fail in non-thread safe ways. > > My counterclaim is that the move to class-based

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 7:05 PM, Patryk Zawadzki wrote: > On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee > wrote: >> Python classes have state. People *will* assign variables to self, >> because that's something they have done with every other Python class >> in existence. And as soon as the

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 1:05 PM, Patryk Zawadzki wrote: > But until Joey appears to give you money (...) s/until/before/ -- Patryk Zawadzki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-devel

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 12:49 PM, Russell Keith-Magee wrote: > Python classes have state. People *will* assign variables to self, > because that's something they have done with every other Python class > in existence. And as soon as their code hits production, their code > will break, in unpredicta

Re: #6735 -- Class based generic views: call for comment

On Sat, Oct 2, 2010 at 6:08 PM, Patryk Zawadzki wrote: > On Fri, Oct 1, 2010 at 3:55 PM, Alex Gaynor wrote: >> On Fri, Oct 1, 2010 at 9:53 AM, Vinay Sajip wrote: >>> On Oct 1, 11:16 am, Johannes Dollinger >>> wrote: Could you (or anyone knowledgable) add a section, that explains why each

  1   2   3   4   >