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:
>
> url("^articles/$", ArticlesView.dispatch).
>
> It seems to address all concerns: it's explicit, safe to assign
> attributes, Pythonic, and fails loudly if used improperly (using
> AritlcesView would result in an Exception being throw since it doesn't
> return an HttpResponse, and using, and ArticlesView() an error about
> not being callable).
After playing around with this for a bit, it seems to be the best option
on the table. The only slight API problem I've come across is that it
is *possible* to try to pass configuration arguments to __init__:
class MyView(View):
def __init__(self, myparam=0):
...
view = MyView(myparam=1).as_view
instead of using configure:
view = MyView.configure(myparam=1).as_view
However, as soon as you try to use that view, you will find that your
custom parameter is being ignored. That might cause some head
scratching to the newbie, but nothing like the insidious thread-safety
problems we're trying to avoid.
Luke
--
"Doubt: In the battle between you and the world, bet on the world."
(despair.com)
Luke Plant || http://lukeplant.me.uk/
--
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...@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.
