[pypy-dev] Re: [pypy-svn] rev 2674 - pypy/trunk/doc

Laura Creighton lac at strakt.com
Mon Dec 22 23:54:32 CET 2003


In a message of Mon, 22 Dec 2003 23:48:18 +0100, holger krekel writes:
>Hi Bengt,
>
>[Bengt Richter Mon, Dec 22, 2003 at 01:17:03PM -0800]
>> At 18:07 2003-12-22 +0100, you (holger krekel) wrote:
>> >Hi Alex,
>> >
>> >[Alex Martelli Mon, Dec 22, 2003 at 05:52:40PM +0100]
>> >> Is there a way, with subversion, to have a simple conformance test f
>or this
>> >> kind of formatting parameters be run automatically, whenever a textf
>ile is 
>> >> committed?  If files breaking these conventions (or whatever convent
>ions
>> >> we can all agree on) were never committed, this would minimize the n
>eed
>> >> for "changes that are purely related to formatting", I think.
>> >
>> >Indeed. A pre-commit hook is able to perform checks like this although
>> >the details might get hairy if you go for "indentation of four-spaces"
> 
>> >enforcement (e.g. considering docstrings) .  I guess i'd go for simpli
>city 
>> >and just enforce "line-length < 80" and svn:eol-style==native for all 
>*.py 
>> >and *.txt files (unless their svn:mime-type is explicitely non-text or
> some
>> >such).  Non-conforming commits would simply be refused and nothing wou
>ld be 
>> >changed on the fly. Opinions? 
>> 
>> Comments from left field (since I wound up a mere lurker after all ;-)
>
>Your are welcome and that can change, anyway :-)
>
>> 1. I could see automated refusal of commits being a nuisance unless the
>re
>>    was an override available.
>
>If we choose transparent and consensual rules and can provide nice error 
>messages i think they should help more then do harm.  Often have people
>checked in files just to find out they did wrong and had to checkin 
>another time ...
>
>> 2. What about a separate pypytidy.py tool that people could use like
>>    a standards-enforcer/beautifier/spell-checker _before_ committing?
>>    Seems like an enforcer-hook would contain much of the logic anyway,
>>    and done separately a useful tool could evolve as a side effect.
>
>we have pypy/tool/fixeol.py although this mainly deals with line
>endings.  Our tools sections is an ever expanding branch of PyPy :-)
>
>cheers,
>
>    holger
>_______________________________________________
>pypy-dev at codespeak.net
>http://codespeak.net/mailman/listinfo/pypy-dev

I am thinking that we need a way to say 'this line purposely longer'.

Big URLS, and  things like:

'Don't write code like this: <blatt code that won't fit on one line>'

Laura


More information about the Pypy-dev mailing list