PEP 8 change in Travis

My PR to squelch the seemingly new tests passes travis. Unless
someone strongly protests, I will merge it later this afternoon so we
can get back to our normally scheduled testing.

If we want to discuss turning some of the tests back on we can have
that discussion later.

Tom

···

On Thu, Mar 27, 2014 at 11:40 AM, Phil Elson <philipelson@...149...> wrote:

I see your point Paul, but from my perspective matplotlib's codebase is
slowly but surely being tidied up, and the consistently styled code is
making it easier to read, maintain and enhance.

Re-quoting Guido:

    Let's try to make new stdlib modules use the best style we
    can think of, but limit the time spent fretting over code
    that's already there.

We've also taken this view and as a result have whole sub-packages which we
do not check the PEP8 tests against
(https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/test_coding_standards.py#L41).
However, I must add that it is actually quite rewarding to go through ugly
code and turn it into something approaching consistent [I encourage you to
try it when the sun isn't shining in California :wink: ], not not mention it
being a great way to get involved in the development of mpl (actually in the
beginning I think that is how Thomas and Nelle became frequent committers).

So in summary I agree they are just *guidelines*, not strict rules, but we
have to maintain a highly collaborative repository of code and we ultimately
need to make it as readable and maintainable as possible - the best way of
doing that IMHO is to automate the testing using tools such as pep8 so that
when we review PRs we only need to focus on behaviour, and not on whether
there are trailing whitespace characters etc.

On 27 March 2014 01:51, Thomas Caswell <tcaswell@...149...> wrote:

At any rate, I have a PR (#2930) that should make it pass cleanly again.

On the bright side, it looks like one of the changes is 1.5 is that
long unbreakable lines will get ignored by E501 so urls are safe
again.

On Wed, Mar 26, 2014 at 6:10 PM, Paul Ivanov <pi@...453...> wrote:
> Nelle Varoquaux, on 2014-03-26 21:27, wrote:
>> > Does anyone know why we are seeing a huge number of PEP 8 failures
>> > now?
>> > It looks to me like it is a change in which modules are subject to
>> > the
>> > test, or in which tests are grounds for failure. I don't know how
>> > all
>> > this is set up, though.
>>
>> If it started very recently, it could be linked to the new release.
>> They
>> have started to make "none backward" compatible version, in the sense
>> that
>> the stylechecker is increasingly strict. It is very annoying...
>
> Can we not revisit (and possibly revert) the morally absolutist
> PEP-8 or death position that matplotlib has taken?
>
> Quoting GvR (emphasis mine):
>
> All I want to say is, people lighten up. The style guide
> can't solve all your problems. You are never going to have
> all code compliant. Use the style guide when it helps, *ignore
> it when it's in the way*
>
> And from that same email:
>
> Let's try to make new stdlib modules use the best style we
> can think of, but limit the time spent fretting over code
> that's already there.
>
>
> The rest of the message is useful to read:
> [Python-Dev] Breaking undocumented API
>
> Another reason for not being so rigid about PEP-8 is that its a
> living document. Are we really doing massive search-and-replace
> changes to the codebase just to comply with a moving target?
>
> best,
> --
> _
> / \
> A* \^ -
> ,./ _.`\\ / \
> / ,--.S \/ \
> / `"~,_ \ \
> __o ?
> _ \<,_ /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> matplotlib-devel List Signup and Options

--
Thomas Caswell
tcaswell@...149...

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Thomas Caswell
tcaswell@...149...