Re: Conforming to pep8

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 9, 2014, 04:36 UTC
Message-ID: <536c5b4d9e2c9_377dfcb2f02b@nysa.notmuch>
In-Reply-To: <20140509035759.GA9051@wst420>

William Giokas wrote:

Show 22 quoted lines

> On Thu, May 08, 2014 at 09:10:25PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8
> > > just getting put by the wayside? I would much rather have these
> > > scripts conform to that and have an actual coding style rather than
> > > just be a hodge-podge of different styles.
> > 
> > Personally I try to follow pep8 in git-remote-{hg,bzr}, but only to some
> > extent.
> > 
> > I do this:
> > 
> >   [pep8]
> >   ignore = E401,E302,E201,E202,E203,E126,E128
> 
> (So I haven't looked at git-remote-bzr, but I can comment on
> git-remote-hg)
> 
> Is there a reason for these?
> 
> E401: Multi-line imports seems like something that would just be
> changing one line

Yes, and make the code very annoying.

> E302: Blank lines don't seem to be that hard to do either. That can even
> be automated quite reliably. It shouldn't detract from the readability,
> juts makes the file a bit longer.

The problem is not that it's hard to do, the problem is that it makes the code uglier.

> E20{1,2,3}: Extra whitespace is something that just makes things more
> consistent and readable.

I don't see how this:

  {'100755': 'x', '120000': 'l'}

Is more readable than this:

  { '100755': 'x', '120000': 'l' }

No strong opinion on this one though.

> E12{6,8}: continuation line indenting is another thing that helps
> consistency.

I don't see how.

> >   max-line-length = 160
> 
> The standard states that this should, at most, be increased to a value
> between 80 and 100.

And why's that?

This has been discussed many times in the LKML, and the end result is
that we don't live in the 60's, our terminals are not constrained to 60
characters. Going beyond 100 is fine.

> Note that I'm not trying to yell, but these are just things that are set
> forth in pep8 but don't seem to be set at all in git-remote-hg. I really
> think that git's python 'bits' should be able to pass a default pep8
> without issue.

And I disagree.

I'm willing to follow pep8 as much as possible as long as it makes sense, but some thing do make the code uglier in my opinion.

Show 5 quoted lines

> > That said there's a couple of issues present that I didn't notice.
> > Thanks for checking.
> 
> Hope to see some improvements! git-remote-hg is really quite useful for
> me, and I hope it can be as good as possible!

Well, too bad Junio has essentially blocked all possible progress on his tree.

I've pushed the fix on mine[1].

Cheers.

[1] https://github.com/felipec/git/commit/12374c0e09a84945a202bb5ba7981a223d233d0b

-- 
Felipe Contreras