PEP8 and Flake8 fixes #4613
PEP8 and Flake8 fixes #4613
Conversation
There was a problem hiding this comment.
The change footprint of this PR is far too large. Not even possible to properly review. (Eg. so many changes that a reviewer could easily miss if an argument signature accidentally changed in between versions)
We really can't accept something like this in the current state. I'd suggest:
- A PR to update everything except the linter.
- A PR to update the linter, with the absolute minimum possible changes in order to continue passing the tests, with our current linting settings.
If the second one of those isn't possible to do with a small footprint then we'll need to reconsider our linter settings, or consider not upgrading, or even opening an issue against the linter package.
If the second one is possible then we could always consider following up with further stylistic changes, but making sure to isolate those down to a single style aspect at a time.
Thanks for your time & effort, hopefully we can reach something that we can accept. 😄
| DecimalField, DictField, EmailField, Field, FileField, FloatField, | ||
| ImageField, IntegerField, ListField, MultipleChoiceField, NullBooleanField, | ||
| OrderedDict, RegexField, SlugField, TimeField, URLField | ||
| ) |
There was a problem hiding this comment.
Is this change strictly necessary?
There was a problem hiding this comment.
In order to use the current linter, yes.
| ]) | ||
| return OrderedDict([(field_name, self.get_field_info(field)) | ||
| for field_name, field in | ||
| serializer.fields.items()]) |
There was a problem hiding this comment.
Is this different indentation style mandatory? It reads less obviously to me. If we can avoid changing it let's do so.
There was a problem hiding this comment.
That's the only indentation style that works within the 79 character limit. Since I only noticed that we're ignoring the line length PEP8 rule after the fact, we don't need to worry about the indentation style changing.
Still, that is the only way to make the linter work and not ignore the line length rule (which I would be in favor of doing). I think the best course of action is to continue ignoring the line length, do everything else, and then decide about the line length at some future date. I would be in favor of the 79 character limit though - it's really easier once you take the plunge...
| } | ||
| for choice_value, choice_name in field.choices.items() | ||
| ] | ||
| field_info['choices'] = [{'value': choice_value, |
There was a problem hiding this comment.
Again, this seems less clear.
| @@ -64,15 +70,16 @@ class JSONRenderer(BaseRenderer): | |||
| # We don't set a charset because JSON is a binary encoding, | |||
| # that can be encoded as utf-8, utf-16 or utf-32. | |||
| # See: http://www.ietf.org/rfc/rfc4627.txt | |||
| # Also: http://lucumr.pocoo.org/2013/7/19/application-mimetypes-and-encodings/ | |||
| # http://lucumr.pocoo.org/2013/7/19/application-mimetypes-and-encodings/ | |||
There was a problem hiding this comment.
We shouldn't have to alter our docstring text in order to keep the linter happy. I'm happy to have strict linting for almost everything, but I think the line length should be a guideline rather than mandatory, because of cases like this where it forces authors to alter what they would otherwise write.
There was a problem hiding this comment.
If/When the decision is made to follow a 79 character line length, the comments should be pulled over too. But since that won't be happening in the short term, the comments will stay the same.
| charset = None | ||
|
|
||
| def get_indent(self, accepted_media_type, renderer_context): | ||
| if accepted_media_type: | ||
| # If the media type looks like 'application/json; indent=4', | ||
| # then pretty print the result. | ||
| # Note that we coerce `indent=0` into `indent=None`. | ||
| base_media_type, params = parse_header(accepted_media_type.encode('ascii')) | ||
| base_media_type, params = parse_header( | ||
| accepted_media_type.encode('ascii')) |
| @@ -260,88 +268,93 @@ class HTMLFormRenderer(BaseRenderer): | |||
| base_template = 'form.html' | |||
|
|
|||
| default_style = ClassLookupDict({ | |||
| serializers.Field: { | |||
| Field: { | |||
There was a problem hiding this comment.
Again, would much rather keep the serializers.<SomeField> style throughout. It's an important bit of namespacing, and we've been very strongly consistent about it's use and recommending it to others. If the linting tool is going to force this to change, then I don't see us accepting that aspect of the linting.
There was a problem hiding this comment.
Agreed. In a new ticket we will use relations. and fields. to replace where serializers. used to be used (since those fields aren't actually in serializers, they were just available because of the import *)
| else: | ||
| serializer = view.get_serializer(**kwargs) | ||
| else: | ||
| # at this point we must have a serializer_class | ||
| if method in ('PUT', 'PATCH'): | ||
| serializer = self._get_serializer(view.serializer_class, view, | ||
| request, instance=instance, **kwargs) | ||
| serializer = self._get_serializer(view.serializer_class, |
There was a problem hiding this comment.
Not convinced by this indentation style. If we must push arguments onto a newline, let's stick with ...
something(
arg1,
arg2
)
Seems far more readable to me than the "push everything up to the initial bracket" style
|
I'll open up a new ticket so we can accept a path before doing the work. I put comments inline - hope that's not too messy. |
Ok, here we go with
serializersadded back as prefixes.fieldsandrelations, which never were module prefixes because usage was passing throughserializersfor the fields and relations are not there. We could add them or not - up to you.