Update pep8 for stressing type hinted long parameter in functions
This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many): https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256... def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle This violates pep8 # Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one) However, no coding styles tools report that. Flake8 does however report a similar error for if conditions if path.suffix in ( '.js', '.json' ): proto = Protocol.json x.py:20:5: E125 continuation line with same indent as next logical line But says nothing for this monstrosity, which is the equivalent of the opening case if path.suffix in ( '.js', '.json' ): proto = Protocol.json It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes() to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice. -- Kind regards, Stefano Borini
IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8. -- Ivan On Wed, 27 Nov 2019 at 11:42, Stefano Borini <stefano.borini@gmail.com> wrote:
This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many):
https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256...
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle
This violates pep8
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
However, no coding styles tools report that. Flake8 does however report a similar error for if conditions
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
x.py:20:5: E125 continuation line with same indent as next logical line
But says nothing for this monstrosity, which is the equivalent of the opening case
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes()
to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice.
-- Kind regards,
Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJ... Code of Conduct: http://python.org/psf/codeofconduct/
Black is a bit weird in some other ways. Like preferring " over '. He has an agenda, he's not trying to codify the de facto style :(
On 27 Nov 2019, at 15:56, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8.
-- Ivan
On Wed, 27 Nov 2019 at 11:42, Stefano Borini <stefano.borini@gmail.com> wrote: This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many):
https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256...
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle
This violates pep8
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
However, no coding styles tools report that. Flake8 does however report a similar error for if conditions
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
x.py:20:5: E125 continuation line with same indent as next logical line
But says nothing for this monstrosity, which is the equivalent of the opening case
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes()
to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice.
-- Kind regards,
Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJ... Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TPZT2U... Code of Conduct: http://python.org/psf/codeofconduct/
Thanks. I'll check black behavior and file an issue there tonight. In any case, the point stands. I think new, rather expected case should be clarified explicitly in the pep. On Wed, 27 Nov 2019 at 14:53, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8.
-- Ivan
On Wed, 27 Nov 2019 at 11:42, Stefano Borini <stefano.borini@gmail.com> wrote:
This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many):
https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256...
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle
This violates pep8
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
However, no coding styles tools report that. Flake8 does however report a similar error for if conditions
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
x.py:20:5: E125 continuation line with same indent as next logical line
But says nothing for this monstrosity, which is the equivalent of the opening case
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes()
to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice.
-- Kind regards,
Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Kind regards, Stefano Borini
I think its fine if Black and PEP 8 disagree. PEP 8 is meant for humans who want to lay out their code maximally readable and consistent, but in many cases allows multiple ways (if both are readable or if it depends on other context). PEP 8 also covers things like naming conventions and how to use comments. Black is meant to stop arguments by enforcing uniform use of whitespace, and to minimize changes to code layout as it evolves. As always, style is a matter of taste. If you disagree with PEP 8, fine. If you don't like Black, don't use it. If you're working in a team, decide as a team. On Wed, Nov 27, 2019 at 7:19 AM Anders Hovmöller <boxed@killingar.net> wrote:
Black is a bit weird in some other ways. Like preferring " over '. He has an agenda, he's not trying to codify the de facto style :(
On 27 Nov 2019, at 15:56, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
IIRC, black actually uses the first style you mention, so maybe you should rather discuss it there first. Otherwise this will create a weird situation where one of the most popular auto-formatter formats code in violation of PEP 8.
-- Ivan
On Wed, 27 Nov 2019 at 11:42, Stefano Borini <stefano.borini@gmail.com> wrote:
This may be a pet peeve of mine, but with the introduction of type hints, more and more function definitions have become longer than 80 characters. This used to seldom happen in the past. The problem, as I see it, is that there seem to be a general tendency to use this way of indenting, e.g. see (among many):
https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256...
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False, ) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickle
This violates pep8
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one)
However, no coding styles tools report that. Flake8 does however report a similar error for if conditions
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
x.py:20:5: E125 continuation line with same indent as next logical line
But says nothing for this monstrosity, which is the equivalent of the opening case
if path.suffix in ( '.js', '.json' ): proto = Protocol.json
It is not my intention to trigger a massive discussion. My stance is that the appropriate visual aspect of the above code should be
def load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes()
to keep a visual distinction in indentation between the argument list and the function body, as in the spirit of pep8. Regardless of the choice, I think that pep8 should be updated with the appropriate style for this specific case, and style tools should enforce this choice.
-- Kind regards,
Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJ... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TPZT2U... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PMDV2R... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
Stefano Borini <stefano.borini-Re5JQEeQqe8Avxtiu Mwx3w@public.gmane.org> Wrote in message:r
This may be a pet peeve of mine, but with the introduction of typehints, more and more function definitions have become longer than 80characters. This used to seldom happen in the past.The problem, as I see it, is that there seem to be a general tendencyto use this way of indenting, e.g. see (among many):https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256... load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False,) -> Any: path = Path(path) b = path.read_bytes() if content_type is None: if path.suffix in ('.js', '.json'): proto = Protocol.json elif path.suffix == '.pkl': proto = Protocol.pickleThis violates pep8# Add 4 spaces (an extra level of indentation) to distinguisharguments from the rest.def long_function_name( var_one, var_two, var_three, var_four): print(va r_one)However, no coding styles tools report that. Flake8 does howeverreport a similar error for if conditions if path.suffix in ( '.js', '.json' ): proto = Protocol.jsonx.py:20:5: E125 continuation line with same indent as next logical lineBut says nothing for this monstrosity, which is the equivalent of theopening case if path.suffix in ( '.js', '.json' ): proto = Protocol.jsonIt is not my intention to trigger a massive discussion. My stance isthat the appropriate visual aspect of the above code should bedef load_file( path: Union[str, Path], *, content_type: str = None, encoding: str = 'utf8', proto: Protocol = None, allow_pickle: bool = False) -> Any: path = Path(path) b = path.read_bytes()to keep a visual distinction in indentation between the argument listand the function body, as in the spirit of pep8.Regardless of the choice, I think that pep8 should be updated with theappropriate style for this specific case, and style tools shouldenforce this choice.-- Kind regards,Stefano Borini_______________________________________________Python-ideas mailing list -- python-ideas@python.orgTo unsubscribe send an email to python-ideas-leave-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJ... of Conduct: http://python.org/psf/codeofconduct/
PEP 8 is the stdlib style guide, and the type annotations are not used in the stdib. --
On Nov 27, 2019, at 09:13, Serhiy Storchaka <storchaka@gmail.com> wrote:
PEP 8 is the stdlib style guide, and the type annotations are not used in the stdib.
PEP 8 already has guidelines for annotations. For example:
Function annotations should use the normal rules for colons and always have spaces around the ->arrow if present. (See Function Annotations below for more about function annotations.)
The linked section also says: The Python standard library should be conservative in adopting such annotations, but their use is allowed for new code and for big refactorings. More generally, everyone knows PEP 8 is not just the style guideline for the stdlib, but the default style for external projects. It devotes quite a bit of wording to the fact that it’s only a default, implicitly (and in a few cases explicitly) acknowledging that it is one. And it already offers guides for a number of things the stdlib never does, like relative imports and coding declarations. There is a plausible reason not to mandate style more explicitly here—in fact, it’s already given in the text: Type hinting is still relatively new, so it’s worth encouraging large projects to experiment within the rules of PEP 484. The question is whether that’s still true, or whether PEP 484 usage is explored well enough by now to start offering guides rather than an invitation to experiment further.
participants (6)
-
Anders Hovmöller -
Andrew Barnert -
Guido van Rossum -
Ivan Levkivskyi -
Serhiy Storchaka -
Stefano Borini