Hi Bruno,
On 3/17/24 4:49 PM, Bruno Haible wrote:
> It is not good if, each time we deal with a list of lines, we have to give
> extra thought to the case of 0 lines. This is only a recipe for
> inconsistencies.
Yes, this change looks much better. Having 'if len(lines) > 0: ...'
everwhere looks messy. Thanks.
Unrelated to the newline change itself, but something I noticed that I
would like to bring up:
def lines_to_multiline(lines):
'''lines_to_multiline(List[str]) -> str
Combine the lines to a single string, terminating each line with a newline
character.'''
In new functions, I have been prefering adding Python 3.7+ type hints
and omitting the repeated function name in doc strings. Like this:
# 'List' requires from __future__ import annotations
def lines_to_multiline(lines: List[str]) -> str:
'''Combine the lines to a single string, terminating each line with a
newline
character.'''
I figured that, once gnulib-tool.py has most/all of it's features
ready, we could do this to the existing functions as code clean up.
Before making that change, it might be worth formalizing doc string
conventions. Right now we use three single quotes and a style similar
to those described in the GNU Coding standards [1]:
/* This is a C comment.
New line. */
'''This is a Python comment.
New line.'''
I don't have strong opinions on the matter, but it is worth mentioning
that some documentation tools such as Docutils or Sphinx expect
certain formats [2] [3]. It may be worth considering this in case we
want to use tools like this in the future.
[1] https://www.gnu.org/prep/standards/standards.html#Comments
[2] https://peps.python.org/pep-0257/#abstract
[3] https://www.sphinx-doc.org/en/master/tutorial/automatic-doc-generation.html
Collin
