On Thursday, August 13, 2015 at 7:03:26 PM UTC+2, James Bennett wrote:
>
>
> As to removing the field from FlatPage, I'm ambivalent enough to be
> against it just because removing it is too much effort. But if a stronger
> argument can be made for getting rid of it, I could change my mind.
>
I d
I think that the compromise is a good idea, but on the long term it implies
the creation of a field in order to support a third party library.
While there are historical reasons it would be best to just let the third
party library solve this problem on its own.
On Wednesday, August 12, 2015 at
27; expects i.e. no
# 'self' argument, but it is a closure over self so it can call
# 'func' correctly.
return bound_func(*args, **kwargs)
The discussion is about the usefulness of this I think.
On Friday, August 7, 2015 at 8:22:51 PM UTC+2, Fabrizio Mess
Sorry did read the commit code now and the new *method_decorator* seems to
solve most of the problem
On Thursday, August 6, 2015 at 11:21:36 AM UTC, Fabrizio Messina wrote:
>
> Hello I would like to ask why the class based views documentation seems so
> much ugly. Some developers pro
oes it help?
>
> Is your proposal to add the reduce() syntax to the docs?
>
> On Thursday, August 6, 2015 at 7:21:36 AM UTC-4, Fabrizio Messina wrote:
>>
>> Hello I would like to ask why the class based views documentation seems
>> so much ugly. Some developers probably
Hello I would like to ask why the class based views documentation seems so
much ugly. Some developers probably are scared by these just because the
decoration is ugly, the documentation offers three ways:
Decorate the *Klass().dispach()* method of the class, wrapping the
decorators in another d
