- Original Message -
> From: "Kamil Paral"
>
> Will we try to live with it in libtaskotron for a while, or should I create
> similar patches for all our projects right away?
I vote for doing it everywhere. I have already converted the ExecDB using
autopep8
`autopep8 -r --max-line-lengt
> > PS: It seems that flake8 can't be configured in arcanist at the
> > moment. The patch was written [1] but abandoned and never pushed [2].
> > It seems quite simple, though, so we could finish that up, if
> > desired. The other approach is to disable line length checking in
> > flake8 and use ge
On 06/13/2015 12:33 AM, Tim Flink wrote:
> On Fri, 12 Jun 2015 09:21:38 -0400 (EDT)
> Kamil Paral wrote:
>
>>>> Back to everyone's favorite topic - coding style and enforcement
>>>> of that style.
>>
>> And I thought we were doing so great by le
On Tue, 16 Jun 2015 06:25:22 -0400 (EDT)
Kamil Paral wrote:
> > After the meeting earlier today, I wanted to make a slightly
> > different proposal.
> >
> > - if flake8 config in arcanist can be so configured, set max line
> >width to 120 instead of 79
>
> On my 1920px monitor, two windows
> After the meeting earlier today, I wanted to make a slightly different
> proposal.
>
> - if flake8 config in arcanist can be so configured, set max line
>width to 120 instead of 79
On my 1920px monitor, two windows with 100 columns fit perfectly next to each
other (11px font). Is there a
On Fri, 12 Jun 2015 00:49:53 -0600
Tim Flink wrote:
> To be more specific, I am proposing the following:
> - all QA devel projects be have flake8 as the linter in arc config
> - no code be accepted with lint errors unless there is absolutely no
>other way to get around it
> - until we get
> First of all I'd suggest to move our codebase to strict PEP8 (or
> as-strict-as-possible), so we can have see how our code looks like, when
> PEP8 compliant.
> For starters, we could just plain use autopep8 -
> https://pypi.python.org/pypi/autopep8/
> How about that?
For the record, Josef put up
On Mon, 2015-06-15 at 06:19 -0400, Josef Skladanka wrote:
> >
> > > > I'm not picking on Josef here - I'm sure I've submitted code
> > > > recently
> > > > with lint errors, this was just the review I was looking at
> > > > which
> > > > triggered the idea:
> > > >
> > > > https://phab.qadevel.
> > > I'm not picking on Josef here - I'm sure I've submitted code recently
> > > with lint errors, this was just the review I was looking at which
> > > triggered the idea:
> > >
> > > https://phab.qadevel.cloud.fedoraproject.org/D389
No worries, I'm not taking it personaly. As I commented in t
On Fri, 12 Jun 2015 09:21:38 -0400 (EDT)
Kamil Paral wrote:
> > > Back to everyone's favorite topic - coding style and enforcement
> > > of that style.
>
> And I thought we were doing so great by leaving it behind...
>
> > >
> > > I'm n
On Fri, 12 Jun 2015 05:16:57 -0400 (EDT)
Martin Krizek wrote:
> - Original Message -
> > From: "Tim Flink"
> > To: qa-devel@lists.fedoraproject.org
> > Sent: Friday, June 12, 2015 8:49:53 AM
> > Subject: Coding Style
> >
> > Bac
> > Back to everyone's favorite topic - coding style and enforcement of
> > that style.
And I thought we were doing so great by leaving it behind...
> >
> > I'm not picking on Josef here - I'm sure I've submitted code recently
> > with lint
- Original Message -
> From: "Tim Flink"
> To: qa-devel@lists.fedoraproject.org
> Sent: Friday, June 12, 2015 8:49:53 AM
> Subject: Coding Style
>
> Back to everyone's favorite topic - coding style and enforcement of
> that style.
>
> I&#
Back to everyone's favorite topic - coding style and enforcement of
that style.
I'm not picking on Josef here - I'm sure I've submitted code recently
with lint errors, this was just the review I was looking at which
triggered the idea:
https://phab.qadevel.cloud.fedoraproject
> > E128
> >
> > libtaskotron/check.py:94:17: E128 continuation line under-indented
> > for visual indent libtaskotron/check.py:97:21: E128 continuation line
> > under-indented for visual indent libtaskotron/check.py:209:21: E128
> > continuation line under-indented for visual indent
>
> > But if there's a strong desire for more columns, I'll manage. Can't hinder
> > the team, can I? :)
>
> Also, we should mention that by default the maximal line length is set to 79,
> not 80.
>
> Let's just set it to 80 (as we already use it in the code), and forget about
> the heretic 100 ide
> > But if there's a strong desire for more columns, I'll manage. Can't
> > hinder the team, can I? :)
>
> It amuses me that you're strongly "80 columns only" for code but are
> pretty anti-column-width-restriction on email :)
Yeah, it's a bit ironic. It's mostly about available tools and how the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/04/2014 02:01 PM, Tim Flink wrote:
> Of the concerns you raised, I'm not terribly opposed to most of
> them other than E128 and E122. I'm not crazy about dropping E265,
> though.
One thing to watch with pep8 is it has the notion of "ignored by
d
On Tue, 3 Jun 2014 09:29:49 -0400 (EDT)
Kamil Paral wrote:
> > Outside any header requirements or directive documentation
> > requirements, are there any changes to PEP8 that folks want to
> > make? If so, please list the exceptions and why you think they
> > should be adopted.
>
> E251 ===
On Tue, 3 Jun 2014 09:44:42 -0400 (EDT)
Kamil Paral wrote:
> > How about:
> >
> > [FORMAT]
> > # Maximum number of characters on a single line.
> > max-line-length=100
> >
> > /me has no problem with 80 chars, but most of my monitors can
> > easily handle two 100-char on one vertically sp
> But if there's a strong desire for more columns, I'll manage. Can't hinder
> the team, can I? :)
Also, we should mention that by default the maximal line length is set to 79,
not 80.
Let's just set it to 80 (as we already use it in the code), and forget about
the heretic 100 idea :)
_
First of all - forget the max-line-length comment from earlier... I went
through the pep8's configuration options, and there is basically next to none,
so the overall decision will mostly need to be "keep it or drop it".
> E251 =
> Josef is used to add spaces between keyword name and it
> How about:
>
> [FORMAT]
> # Maximum number of characters on a single line.
> max-line-length=100
>
> /me has no problem with 80 chars, but most of my monitors can easily handle
> two 100-char on one vertically split-view in vim (and 80 chars is sometimes
> quite a pain)
Traitor!
I can't
> Outside any header requirements or directive documentation requirements,
> are there any changes to PEP8 that folks want to make? If so, please
> list the exceptions and why you think they should be adopted.
E251 =
libtaskotron/directives/bodhi_comment_directive.py:247:67: E251 unexpec
> Outside any header requirements or directive documentation requirements,
> are there any changes to PEP8 that folks want to make? If so, please
> list the exceptions and why you think they should be adopted.
How about:
[FORMAT]
# Maximum number of characters on a single line.
max-line-len
Since we're likely to be doing some license header changes in the near
future, I'm thinking that it might be a good time to start discussing
code style for our projects.
I'd like to be pretty much pep8 unless there are good reasons to
deviate from that standard. PEP8 is well known and tools to che
26 matches
Mail list logo
