A less naive strategy for getting view closure var

[mverteuil]

• Handles a particular class of decorated view functions that refer to the outermost closure arguments.
• Searches for a types.FunctionType argument in the closure, rather than assuming the first
  argument is the view. This is a correct implementation for existing cases as well.

[ariovistus]

what's your use case that the current implementation doesn't cover?

[mverteuil]

I have decorated views that are not being unwrapped correctly, and thus not documented, because 0th index is not a sufficient condition in all cases.

That the view argument is of FunctionType is necessarily true, and provides some flexibility. That flexibility means the difference between whether DRS actually documents the majority of my views, instead of ignoring them because of something trivial.

[ariovistus]

Could you post an example view? I'm curious, and also I want something in the test suite for this.

[mverteuil]

Sure. I was trying to craft a test for this on my lunch break yesterday, but the tests file is quite the behemoth and is light on the intent comments and docstrings. I will take another stab at it.

[mverteuil]

I had assumed the bug was larger than it was. However, I've managed to isolate it.

I copied the ViewSets which had issues, then excised until only the code required to exercise the bug remained.

• ed84746 80535a2 contains the tests which exercise the bug
• 763711b 1a7c0c3 contains the fix.

[ariovistus]

sweetness!
linter doesn't like you (I've noticed github doesn't seem to notify the pull requester when travis fails, so just making sure you're aware)

[mverteuil]

I keep getting dinged on my amended commits because I'm doing that after running tox. One sec.

[mverteuil]

Pushed a linter friendly version of decorators.py

[mverteuil]

Working on the test failure now.

[mverteuil]

Fixed. I wasn't using the 2/3 compatible form of im_func.

[ariovistus]

your for more info link in the decorator doc doesn't seem to go anywhere?

[mverteuil]

I see, it looks like the original branch is now gone, but I don't have a SHA to point to it.

I've been using a version that was proposed in a Django ticket for years now, that code essentially comes from this patch: https://code.djangoproject.com/attachment/ticket/14512/ticket14512.diff

Usually this decorator wraps other decorator invocations that are meant for decorating an FBV. I've simply unwrapped the wrapped decorator and that's where the name 'squashed' comes from. 'Unwrapped' may have been a better choice, but I didn't want to use that term because it has a slightly different (albeit similar) meaning in decorators.py.

I've found a shorter version, here, which isn't EXACTLY the same thing but seems to be for my purposes:
http://stackoverflow.com/questions/6069070/how-to-use-permission-required-decorators-on-django-class-based-views

The tricky thing here is, the shorter version does not seem to exercise the bug because of how it's constructed. Since the scoping is a bit different when method_decorator is used for the inner decoration, it doesn't seem to mess with the freevars. In any event, I still feel like relying on the coincidence of argument position is more fragile and less correct than relying on the fact that the view callable must necessarily be an instance that is FunctionType. While FunctionType type is still a coincidental detail, it has more of a chance to be right. The first argument will then need to also be a FunctionType, and so any time the previous predicate was a true positive it will also be so in this case. Additionally where it was a false positive, it will no longer be one, and where it was a false negative at least there's now an opportunity to find the view callable in other positions.