[pytest-dev] [proposal] big flake8 cleanup before the 3.1 release

[Oliver Bestwalter]

Hi all,

I usually have all flake8 on full throttle and let PyCharm warn me (except
for naming, I am a bit particular there I admit) and I have similar
thoughts when wondering through the tox sources. I will watch how you do it
and then maybe propose the same for tox afterwards.

Good luck,

Cheers
Oliver


On Fri, 17 Mar 2017 at 11:49 Bruno Oliveira <nicoddemus at gmail.com> wrote:

> Hi,
>
> While this kind of change is a little disruptive regarding history and
> might generate conflicts in PRs, it is the kind of change that is a little
> pain for a short time but brings tangible benefits in the long term, so
> I'm +1 on the idea.
>
> An idea: when doing something similar at work (recently we switched our
> import-order sorting to PEP8 from a custom standard for example) we use a
> fictional persona for the committer of the change as to not assign undue
> "blame" to a person, so I suggest doing the same here. We can use our own
> pytest's bot for that.
>
> Cheers,
> Bruno.
>
> On Fri, Mar 17, 2017 at 6:35 AM Florian Schulze <mail at florian-schulze.net>
> wrote:
>
> Hi!
>
> Personally I disable the line length limit and keep all other warnings.
>
> For old projects I only fix pep8 issues in code I edit in a commit. A
> massive cleanup disrupts history and especially "blame" too much IMHO.
>
> Regards,
> Florian Schulze
>
>
> On 17 Mar 2017, at 10:09, Ronny Pfannschmidt wrote:
>
> > Hi all,
> >
> > before releasing 3.1 i would like to bring pytest up to coding
> > standards
> > while not all agree on the exact rules of flake8,
> > i find it an insult to my eyes to that basically all tools that
> > don't/can't support all kinds of config files
> > pretty much show about half of pytest in violation all the time
> >
> > what i certainly don't want to do, is start to disable code standard
> > enforcement on random projects,
> > so i want to enforce it - and that means fixing up pytest once and for
> > all.
> >
> > a good point in time would e to do it on the features branch right
> > before doing a release and merging back to master as it would create
> > the
> > smallest merge effort.
> >
> > additionally it would allow us to switch from travis for linting to a
> > dedicated service with better gh integration in future without
> > maintaining yet another massive exclude list
> >
> > -- Ronny
> >
> > _______________________________________________
> > pytest-dev mailing list
> > pytest-dev at python.org
> > https://mail.python.org/mailman/listinfo/pytest-dev
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170317/660b9daa/attachment-0001.html>