Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Simon Marchi <simon.marchi@ericsson.com>,
	       GDB Patches <gdb-patches@sourceware.org>,
	       Alan Hayward <Alan.Hayward@arm.com>, nd <nd@arm.com>
Subject: Re: [PATCH v2] Implement timestamp'ed output on "make check"
Date: Mon, 26 Nov 2018 17:22:00 -0000	[thread overview]
Message-ID: <6e9a79a554304065c666c184536f1e1b@polymtl.ca> (raw)
In-Reply-To: <87mupv3ir3.fsf@redhat.com>

On 2018-11-26 11:29, Sergio Durigan Junior wrote:

>>> And FWIW, I don't really like this part of PEP8 which
>>> states that there should be no spaces before parentheses.
>> 
>> If you hate it that much, feel free to propose a change to our
>> standards :)
> 
> Sorry if it appeared that I was complaining about your email!  Not my
> intention at all, and I do appreciate your reviews.

No harm felt on this side, my response could be interpreted a bit 
harshly too, sorry about that.

> As for proposing a change to the standards...  that's a good idea!  
> I've
> played a little bit with "autopep8" here, and it seems to be a nice
> little tool which offers the possibility of ignoring parts of the PEP8
> spec when fixing the file.  For example, for the specific case of
> "whitespace before '('", if you do:
> 
>   autopep8 --ignore E211 -i FILE
> 
> It will not fix the "issue", and will preserve the whitespaces there.
> Neat.

I think autopep8's goal is to enforce pep8 (hence the name), so you 
might not be able to have it format the code in different ways (just 
ignore the warnings, as you pointed out).  But there might be other 
Python formatting tools that are more configurable.  If there's one that 
works well, which we can instruct to add spaces before parentheses (to 
match how we format C/C++ code), then I think it would be reasonable to 
do that.

But otherwise, it just feels we are just swimming against the current, 
since pep8 is recommended by the language implementation itself, and 
most tools revolve around that.

> Anyway, I just wanted to document that I found a way to disable this
> specific extension.  As much as I'd like us to change this specific
> thing, I'll focus on other priorities right now.

:)

Simon


  reply	other threads:[~2018-11-26 17:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 22:12 [PATCH] " Sergio Durigan Junior
2018-11-23 14:42 ` Alan Hayward
2018-11-23 15:03 ` [PATCH v2] " Sergio Durigan Junior
2018-11-23 18:23   ` Simon Marchi
2018-11-25 16:24     ` Sergio Durigan Junior
2018-11-25 19:56       ` Simon Marchi
2018-11-25 23:23         ` Sergio Durigan Junior
2018-11-26  0:47           ` Simon Marchi
2018-11-26 16:29             ` Sergio Durigan Junior
2018-11-26 17:22               ` Simon Marchi [this message]
2018-11-26 18:48           ` Sergio Durigan Junior
2018-12-05 19:39 ` [PATCH] " Pedro Franco de Carvalho
2018-12-05 19:48   ` Sergio Durigan Junior
     [not found]     ` <87sgzbohzb.fsf@linux.vnet.ibm.com>
2018-12-05 20:26       ` Sergio Durigan Junior
2018-12-06 15:30         ` Pedro Alves
2018-12-06 15:54           ` Pedro Alves
2018-12-06 19:32             ` Pedro Franco de Carvalho
2018-12-06 19:52               ` Sergio Durigan Junior
2018-12-07 20:06                 ` Pedro Alves
2018-12-07 22:09                   ` Sergio Durigan Junior
2018-12-08 12:58                     ` Pedro Alves
2018-12-08 23:16                       ` Sergio Durigan Junior
2018-12-09  8:57                         ` Philippe Waroquiers
2018-12-06 19:41         ` Pedro Franco de Carvalho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e9a79a554304065c666c184536f1e1b@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=Alan.Hayward@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.com \
    --cc=sergiodj@redhat.com \
    --cc=simon.marchi@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox