Added nested included serializer support for remapped relations

[sliverc]

In ResourceRelatedField it is possible to rename/remap a field so it can be represented in the api with a different name using the source attribute. This works well however if I request to include this relationship in included it won't be returned.

I have added a test which should make it clearer what issue this PR addresses.

[mblayman]

Hey, @sliverc, this branch now has some conflicts because of the work you did on the flake8 branch. Could you fix that up and also add a CHANGELOG entry for this too? I'm not sure I'll have time to review this today, but I will get to it when I can. Thanks!

[sliverc]

@mblayman Solved merge conflicts and added CHANGELOG entry

[codecov-io]

Codecov Report

Merging #347 into develop will increase coverage by 0.27%.
The diff coverage is 96.55%.

@@             Coverage Diff             @@
##           develop     #347      +/-   ##
===========================================
+ Coverage    76.86%   77.13%   +0.27%     
===========================================
  Files           50       50              
  Lines         6013     6036      +23     
===========================================
+ Hits          4622     4656      +34     
+ Misses        1391     1380      -11

Impacted Files	Coverage Δ
example/tests/test_serializers.py	100% <ø> (ø)	⬆️
example/serializers.py	100% <100%> (ø)	⬆️
example/tests/integration/test_includes.py	100% <100%> (ø)	⬆️
rest_framework_json_api/renderers.py	64.02% <94.73%> (-0.05%)	⬇️
rest_framework_json_api/pagination.py	54.81% <0%> (-0.14%)	⬇️
example/models.py	66.95% <0%> (-0.13%)	⬇️
rest_framework_json_api/serializers.py	88.46% <0%> (ø)	⬆️
rest_framework_json_api/utils.py	90.61% <0%> (+0.81%)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dec89af...5023383. Read the comment docs.

[mblayman]

Could you please add a docstring which provides a conceptual overview of what's going on here? I'm finding the four nested levels to be really intense. If you could use PEP 257 style, that would be great.

"""Extract ...

<relevant details that might help understand what's going on here>
"""

This many levels of exceptions makes me wonder if there might performance challenges here (because of the cost of going through the exception stack over and over). I don't think it's fair to ask you for a performance test so I'm mostly wondering "out loud" if this is too much exception handling as a way to do control flow. It does feel like a bit of a code smell. Maybe that's the cost of working with a spec that's so dynamic ¯\(ツ)/¯

[sliverc]

I have added a docstring.

Considering the levels of exceptions I also think this is certainly not ideal but I cannot think of an alternative way to do it though.

For example calling getattr with default argument None wouldn't work, as an attribute could actually be None. Calling hasattr wouldn't make things better either as internally it also does a try-except (https://docs.python.org/3/library/functions.html#hasattr).
It could be argued whether the serializer method case is really needed but otherwise I guess we will need to live with it.

[mblayman]

Thanks for thinking about it. The only alternative that I can think of is to have multiple returns. What do you think of something like the following:

         try:
             return getattr(resource_instance, field_name)
         except AttributeError:
             pass

         try:
             # For ManyRelatedFields if `related_name` is not set
             # we need to access `foo_set` from `source`
             return getattr(resource_instance, field.child_relation.source)
         except AttributeError:
             pass

        <and so on...>

Is that any "better?" Or is it worse? It would remove the deep nesting even if the logic is functionally the same.

[mblayman]

Thanks, @sliverc. I think this will work well. I appreciate the contribution and dialog.