Clarify View.as_view() docs in respect to functions passed as kwargs.

[Gabriel Grant]

Problem:

At the moment, generic.base.View.as_view() passes kwargs to the class' init (which setattrs them), rather than dynamically subclassing. The ​introductory generic view docs, however, seem to imply that passing kwargs to the as_view() method is equivalent to overriding the class. For example, it ​refers to "pass[ing] the new attributes into the as_view method call" as an "overriding pattern." This makes it rather surprising that functions passed to as_view() aren't bound to the resultant instance.

Possible Resolutions:

It seems to me that as_view() should dynamically create a subclass with the provided kwargs. Alternatively, if that is deemed undesirable, the docs should at least be clarified to better explain the true behaviour.

I can provide a patch, but need someone (*cough* RKM :) to confirm the desired behaviour.

[Russell Keith-Magee]

As discussed on IRC: I'm not sure I see why we should make the implementation of the generic view base class a whole lot more complicated in order to allow users to avoid creating a subclass. Passing arguments in to as_view() is a convenience for the really simple cases -- it isn't intended as a way to avoid ever needed to create a View subclass.

However, I can see how the phrasing about "overriding pattern" could lead to this expectation, so that should be cleaned up.

[Jacob]

Milestone 1.3 deleted

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Tim Graham]

Not sure if this patch was in response to this ticket, but this looks related at least: ​https://github.com/django/django/pull/314

[Tim Graham]

I've merged the pull request above, but it seems like there may be additional clarification that should be added (not sure what exactly).

[Tim Graham]

@gg, if you can provide a patch please reopen. Otherwise, I'm not sure what further clarification (if any) is needed here.