PEP 8 change in Travis

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.

Eric

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

···

Eric

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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:
https://mail.python.org/pipermail/python-dev/2010-November/105681.html

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

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:
https://mail.python.org/pipermail/python-dev/2010-November/105681.html

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
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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