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 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 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/

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 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 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 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-c...

On Nov 27, 2019, at 09:13, Serhiy Storchaka 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.