This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ 17588 13064] Update UTF-8 charmap and width to Unicode 7.0.0


On Mon, Dec 22, 2014 at 08:52:41PM -0200, Alexandre Oliva wrote:
> I had somehow got the idea that there had been broad discussion about
> our python standards, particularly about pylint rules and limits, but
> all I could find was this section without any backing up references:
> https://sourceware.org/glibc/wiki/Style_and_Conventions#Code_formatting_in_python_sources
> and the thread in which the pylintrc file was proposed and introduced
> doesn't seem to have discussed these specific limits at all:
> https://sourceware.org/ml/libc-alpha/2013-12/threads.html#00897
>

We did not specifically discuss all of the items in the pylintrc file.
Mike and I agreed (and nobody objected) that it would be a good idea
to have overall PEP8[1] compliance for our python code with the exception
of some additional glibc-isms.

[1] https://www.python.org/dev/peps/pep-0008/

> Siddhesh, since you pointed myself and Mike to pylint, and you installed
> the file and presumably the section above in the wiki, can you provide
> any pointers or reasons to justify the limits set forth in pylint?

The LOC limitation was not discussed and it has been inherited from
the default pylintrc.  We can set it to a large number if we expect to
have arbitrarily large python modules in our code.

> I'm particularly interested in rationales behind the limits on file size
> and function complexity (branch count), that appear to be so narrow as
> to discourage detailed self-testing.

Likewise for branch count.  Justify it and post a patch to modify the
pylintrc.

> Meanwhile, Mike, in case you have not yet reviewed the glibc style and
> conventions for python, and Mike Frysinger's review of Siddhesh's patch
> in the thread above, and raise any concerns you might have about the
> standards there?  If we're going to revisit glibc's python coding
> standards WRT file size and function complexity, we might as well
> revisit other issues that AFAICT have not been discussed, and then
> review the newly-proposed code so as to fit whatever consensus emerges
> from it.

Or we could do it on a case by case basis as folks hit limitations
that don't seem to align with what we want to have in glibc.

> One issue that springs to mind is the requirement for python2.7
> compatibility.  I'm pretty sure we have used python3-only features, and
> I hope we don't have to rewrite them into less readable variants just
> for python2.7 compatibility, for scripts that would only have to be
> rerun at Unicode version updates.  I'm assuming we'll keep on holding
> the generated ctype and utf8 files in the source repository.

I believe the python code we have written so far in glibc is 2.7 as
well as 3 compliant.  I haven't had a proper look at it though, so I
could be wrong.

Siddhesh

Attachment: pgpNB_W3VwvvU.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]