Open Stack

On 4/18/19 9:00 AM, Monty Taylor wrote:
>
>
> On 4/18/19 1:45 PM, Sean McGinnis wrote:
>>> I think we already use flake8 openstack-wide, what will Black bring
>>> us in
>>> addition to that?
>>>
>>> Dmitry
>>
>> Based on my quick test, it would bring us code churn of changing ' to
>> " and
>> flake8 errors due to unwrapping lines and making them longer than 80
>> characters.
>>
>> I like the idea of code consistency. But having a tool automatically
>> do it
>> without being able to tweak the settings, and having defaults do
>> things that
>> introduce pep8 errors, seems like a non-starter.
>>
>> And as mentioned elsewhere, introducing something like this to a long
>> established code base has a lot of problems. Maybe new projects just
>> starting
>> off may want to investigate further, but running on most projects
>> could be a
>> nightmare.
>
> I agree.
>
> I actually looked at black a little while ago for openstacksdk -
> because I do like me some strict style rules. The long-line-length
> sucked, although making a tox env that passes a reasonable line-length
> worked around that.
>
> The biggest problem is that, even in a pretty clean codebase that
> already tries to follow a lot of what black likes (line breaks after
> brackets - yes please!) - the churn was MASSIVE and really just not
> worth it.
>
> If we were starting OpenStack from-scratch today, I'd recommend we
> adopt it. But we're not.
>
> Also - if new projects decided to adopt black, we'd wind up with two
> conflicting codestyles across OpenStack, which is one of the things
> our long-standing gating on pep8 is supposed to prevent. I don't think
> it's a good idea for OpenStack to _partially_ adopt black.

++

Conflicting code styles is just going to raise the cognitive bar for
contributors. If black's conventions are too restrictive, but we still
want more consistency, someone can drive an effort to start writing down
conventions we, as in OpenStack, think are important. Maybe our desired
conventions are closer to black's than we originally anticipated. Maybe
they're not.

Regardless, it seems the underlying issue is applying any convention to
a large codebase.

>
> Monty
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190418/eec67635/attachment.sig>