[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