Re: GOP-PROP 1: python formatting

[Graham Percival]

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