This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] [BZ 17588 13064] Update UTF-8 charmap and width to Unicode 7.0.0
- From: Pravin Satpute <psatpute at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Mike FABIAN <mfabian at redhat dot com>, libc-alpha at sourceware dot org, Jens Petersen <petersen at redhat dot com>
- Date: Tue, 3 Feb 2015 09:14:07 -0500 (EST)
- Subject: Re: [PATCH] [BZ 17588 13064] Update UTF-8 charmap and width to Unicode 7.0.0
- Authentication-results: sourceware.org; auth=none
- References: <573624784 dot 8871393 dot 1416848051220 dot JavaMail dot zimbra at redhat dot com> <orzjb3o7yf dot fsf at free dot home> <s9dy4qir6fu dot fsf at ari dot site> <orfvce7y90 dot fsf at free dot home> <s9d388duu5r dot fsf at ari dot site> <orioh35mbq dot fsf at free dot home> <20141223111038 dot GA5172 at spoyarek dot pnq dot redhat dot com>
Top-posting: Update on this patch.
We have proposed this as a feature in Fedora 22 (a)
Its alpha freeze is happening on Feb 24. It will be very good for us if this patch get in either in Glibc upstream as well in Fedora. We will get more testing.
Mike has updated script to fix pylintrc warnings. [b][c] I feel it reduce readability and make it more complex.
To me more challenge is getting testing of updated Unicode data. I think we can get it with Fedora 22 Alpha. Will be great if we can make it before Alpha freeze.
Let me know if we need Fedora specifc bug for same.
----- Original Message -----
From: "Siddhesh Poyarekar" <firstname.lastname@example.org>
To: "Alexandre Oliva" <email@example.com>
Cc: "Mike FABIAN" <firstname.lastname@example.org>, "Pravin Satpute" <email@example.com>, firstname.lastname@example.org, "Jens Petersen" <email@example.com>
Sent: Tuesday, December 23, 2014 4:40:38 PM
Subject: 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:
> and the thread in which the pylintrc file was proposed and introduced
> doesn't seem to have discussed these specific limits at all:
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 compliance for our python code with the exception
of some additional glibc-isms.
> 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
> 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.