[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
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. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/WTKPJRYZT7XBU2AELDLSQWANY3C3ELS4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
Stefano Borini 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/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47def
> 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.jsonelif 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 conditionsif 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 caseif
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/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/Code
of Conduct: http://python.org/psf/codeofconduct/
PEP 8 is the stdlib style guide, and the type annotations are not
used in the stdib.
--
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/NW6DP6S7TA32BGG4T26DWVIUMSJDFYMH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
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/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>>
>> 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-le...@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/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/TPZT2URLT47OL2PO746AXODLBIYTQB6K/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/PMDV2RW5EDTTRLNEH3TFKG4PCYYJF4SK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
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 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/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>>
>> 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-le...@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/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/MSA5KHWWCUOH5I6UJHBBP4A6XZXLQDUF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
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/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>>
>> 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-le...@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/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@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/TPZT2URLT47OL2PO746AXODLBIYTQB6K/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/PMDV2RW5EDTTRLNEH3TFKG4PCYYJF4SK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
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/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>
> 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-le...@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/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/TPZT2URLT47OL2PO746AXODLBIYTQB6K/
Code of Conduct: http://python.org/psf/codeofconduct/
