[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GOP-PROP 1: python formatting
From: |
Graham Percival |
Subject: |
Re: GOP-PROP 1: python formatting |
Date: |
Mon, 6 Jun 2011 11:03:59 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
On Mon, Jun 06, 2011 at 10:58:11AM +0200, Karl Hammar wrote:
> Graham:
> > (this proposal will be rushed because nobody will argue against
> > it. Initial discussion 6 June, summary and tentative decision 8
> > June, implementation 10 June)
>
> Having set a policy about policy discussions and then breaking it
> the first thing you do is not a good policy.
>
> If there is no rush, don't break the rules. On the contrary, how
> can I feel confidence in the rules if they are beeing broken.
Very good point.
I felt a bit of a rush because the mix of indentation is delaying
some much-needed improvements to our build system, but I agree
that this was completely contrary to my "let's take time to make
sure it's good" approach.
I have adjusted the schedule accordingly.
> > * never max tabs and spaces
>
> In the code I presume, in strings this wouldn't apply.
Yes.
> > * Code indented with a mixture of tabs and spaces should be
> > converted to using spaces exclusively
>
> Presenting rules without rationales, gives no ground for decisions.
> One could the feeling that this is pure nonsense. If you really
> care about this, provide a pretty printer instead, and stipulate
> that all code should go through that.
I am not aware of any pretty printers for python code -- remember
that unlike C++ or scheme, indentation in python is the way that
one indicates code blocks. (this makes mixing tabs and spaces
particularly horrible!)
I will certainly be giving specific recommendations for a pretty
printer for C++ when we get to that stage, but as far as I know,
the identation of python files must come from a human.
> I propose instead:
>
> . Don't ever provide patches whith white space changes (in the code)
> unless the patch is only about white space changes
I will need to think about that a bit more -- I don't think it
will be necessary for python files.
Cheers,
- Graham
- GOP-PROP 1: python formatting, Graham Percival, 2011/06/05
- Re: GOP-PROP 1: python formatting, Michael Welsh Duggan, 2011/06/05
- Re: GOP-PROP 1: python formatting, Werner LEMBERG, 2011/06/06
- Re: GOP-PROP 1: python formatting, Martin Tarenskeen, 2011/06/06
- Re: GOP-PROP 1: python formatting, Ian Hulin, 2011/06/06
- Re: GOP-PROP 1: python formatting, Patrick McCarty, 2011/06/06
- Re: GOP-PROP 1: python formatting, Trevor Daniels, 2011/06/06
- Re: GOP-PROP 1: python formatting, Karl Hammar, 2011/06/06
- Re: GOP-PROP 1: python formatting, Jan Warchoł, 2011/06/06