matplotlib-devel Mailing List for matplotlib

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 <phi...@gm...> 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 ;) ], 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 <tca...@gm...> 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...@be...> 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
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Thomas Caswell
tca...@gm...

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...@be...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...