[pypy-dev] Re: [pypy-svn] rev 2674 - pypy/trunk/doc
aleaxit at yahoo.com
Mon Dec 22 18:17:12 CET 2003
On Monday 22 December 2003 06:07 pm, holger krekel wrote:
> > > several times i think it makes sense to think of some convention which
> > > allows the diffs to stay readable.
> > >
> > > Maybe (especially) ReST-changes should be done with a two-step
> > > approach: first the one where you can read the content diff and then
> > > the one (if neccessary at all) which has purely formatting changes and
> > > says so in the commit message. And we might also think about a common
> > > line width so that not everybody reformats the text again and again :-)
> > Yes, good points. I think line length of <80, indents of 4 spaces, no
> > tabs, no traling spaces allowed on any line under any pretext whatsoever,
> > would be good conventions; I find it extremely hard to edit files (be
> > they sources, ReST, or any other text) that fail to meet these
> > conventions.
> For python source files this is fine for me. I am not entirely sure for
> ReST especially since you can have verbatim-blocks (say an excerpt from a
In this case, the checker should be more smart -- know something about
ReST syntax, if it's crucial to allow "verbatim blocks" to break what would
otherwise be the conventions (particularly if we enforce them, see below).
> > Is there a way, with subversion, to have a simple conformance test for
> > this kind of formatting parameters be run automatically, whenever a
> > textfile is committed? If files breaking these conventions (or whatever
> > conventions we can all agree on) were never committed, this would
> > minimize the need 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 simplicity
I would agree, as I don't see the need for "verbatim blocks" in our docs,
but you're the one who brought the subject up so I guess you must have
something in mind about them?
As for Python's docstrings, again the checker should be a bit more
smart (use Python's tokenizer to check indent lengths but not within
multistring literals). But as a first pass we can surely "not enforce this
yet" (it will only mean a few more "formatting only" changes needed).
> and just enforce "line-length < 80" and svn:eol-style==native for all *.py
...and no tabs and no trailing spaces on lines...? Doesn't seem any more
complicated than line length and eol-style (or am I missing something?).
> and *.txt files (unless their svn:mime-type is explicitely non-text or some
> such). Non-conforming commits would simply be refused and nothing would be
> changed on the fly. Opinions?
Full agreement on refusing nonconforming commits (ideally with a clear
message). One issue is that the existing files are sure to contain a lot of
violations. If we start enforcing the rules, then perhaps to commit a tiny
change somewhere in a file with a lot of violations one would have also to
undertake a massive reformatting-only exercise. Perhaps we could enforce
the rules only when the file is new OR the existing file (i.e. the version
before the commit) respects the rules...?
More information about the Pypy-dev