Worked around method_decorator problem with custom getattr

[dpwrussell]

When using django's method_decorator on a Class Based View, decorators with arguments will fail because the method_decorator blindly tries to copy an attribute that an instance does not have, __name__. This is really something that django need to sort out (https://code.djangoproject.com/ticket/13879), so we can probably undo it this the future.

Resolves https://trac.openmicroscopy.org.uk/ome/ticket/11732

Also, switch to using python's functools instead of legacy django.utils.functional.

[atarkowska]

I don't see problems with merging this code. @manics do you have any comments?

[manics]

@aleksandra-tarkowska I'm not familiar enough with Django.

[joshmoore]

@knabar / @cneves / @chris-allan : any opinions?

[knabar]

@joshmoore Looks good as a temporary patch

[chris-allan]

For reference, the Python bug (only "fixed" in 3.3+), how the Django team fixed this issue with cache_page() and the resultant method in django.util.decorators which handles missing attributes:

• http://bugs.python.org/issue3445
• https://code.djangoproject.com/ticket/13093
• https://github.com/django/django/blob/c3aa2948c6c14862407501290571f858ccf45b07/django/utils/decorators.py#L73

The amount of hackery here is pretty significant. These commits need to be annotated better. At a minimum I would like to see these commits annotated with the ticket numbers. If re-writing history is a problem then the comments should be extended to include them.

[dpwrussell]

I will unify this into a single commit with the issues in the commits, I'll put them in the code as well. It would also be possible to instead write our own version of method_decorator. Something like this:

https://gist.github.com/dpwrussell/7573003#file-test3-py

[chris-allan]

Sounds good.

@knabar and I were also discussing our own version of method_decorator() but it's kind of six of one, half a dozen of another as far as hackery goes. It also has the added requirement of needing to have explicit instructions in our documentation to use our version. Not to mention the the subsequent frustration for plugin developers that miss that.

What would obviously be ideal is if the Django project would expand method_decorator() to use available_attrs() as their make_middleware_decorator() already does. Maybe we should PR to that effect as the status of ticket13093 on the Django side of things is basically dead? It's not going to help us in the short term but would show that at least we're willing to be good citizens in that community.

shrugs Up to you.

[dpwrussell]

https://code.djangoproject.com/ticket/21513#ticket

I created a new one rather than tack it onto https://code.djangoproject.com/ticket/13879 as in that ticket they are now talking about adding method_decorator_with_args which is not what my PR addresses.

[chris-allan]

Annotated as discussed and while ugly is rather innocuous. Assuming we have no issues over the next day or so this should be ready to merge.

[chris-allan]

s/deocrator/decorator/

[dpwrussell]

@chris-allan Fixed and squashed 'deocrator' typo.

[joshmoore]

Things have been relatively quite over the past 2 days. Merging as discussed.

[dpwrussell]

Can I rebase this onto 4_4? It shouldn't change any behaviour for any existing (well, excluding 3rd parties who would have to have worked around this in some other way in the unlikely event they encountered it) code.

[dpwrussell]

--rebased-to #1928

[dpwrussell]

FYI: My change has now been merged upstream.

django/django#1997

[joshmoore]

Is there any cleanup that should be planned based on 1997?

[dpwrussell]

I will keep an eye on the django releases and when this commit makes it into a stable django release then we could bump and cleanup, but until then it's still necessary.