← Back to team overview

duplicity-team team mailing list archive

Re: Help with unicode branch (for Python3 support)

 

I'll merge it this weekend.  Fighting with a new router today.  😏

On Sat, Dec 2, 2017 at 10:36 AM, Aaron <lists@xxxxxxxxxxxxxxxxxx> wrote:

> Sorry Ken, I had already submitted my branch for merging before I saw this.
> On 01/12/17 20:43, Kenneth Loafman wrote:
>
> Hi Aaron,
>
> Not sure about adding ANSI_X3.4-1968.  That would mean that the system
> indeed hand locale specified properly.
>
> The values 'ascii' and None were returned when locale was not specified at
> all (detached or cron jobs on some setups).  ANSI implies a proper locale
> setting.
>
> ...Ken
>
> I am not sure I see the conceptual distinction between ascii and ANSI_X3.4-1968
> in this context. I believe ANSI_X3.4-1968 is an alias for ASCII and is
> often also a default when things are misconfigured -- a quick Google brings
> up a bunch of "why does x return ANSI_X3.4-1968 instead of y", e.g.:
> https://stackoverflow.com/questions/44344458/why-does-
> locale-getpreferredencoding-return-ansi-x3-4-1968-instead-of-utf-8
> "Since in your locale LC_ALL is not set, the ASCII default (“ANSI
> X3.4-1968”) is used (this might answer your question in the title)."
>
> I agree there is some risk of a system deliberately configured as ANSI_X3.4-1968
> will be misinterpreted as UTF-8, but think that same risk exists with the
> recent change to make 'ascii' default to UTF-8. As the code/my branch is
> currently, this global is only used for reading encoded text and, as UTF-8
> is a superset of ascii/ANSI_X3.4-1968, I cannot see how it could go wrong
> unless/until somebody also uses that global for writing.
>
> If you do not want to merge this approach, I would really appreciate
> further thoughts on how else to get past the pexpect/testing environment
> being misdetected as ANSI_X3.4-1968, as I'm at a bit of a loss.
>
> Kind regards,
>
> Aaron
>
>

Follow ups

References