Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-03-12 Thread Nick Coghlan 
On 12 March 2017 at 22:57, Nick Coghlan  wrote:

> However, I'm also open to having [PYTHONCOERCECLOCALE=0] also disable the
> runtime warning from the shared library.
>

Considering this a little further, I think this is going to be necessary in
order to sensibly handle the build time "--with[out]-c-locale-warning" flag
in the test suite.

Currently, there are a number of tests beyond the new ones in
Lib/test/test_locale_coercion.py that would need to know whether or not to
expect to see a warning in subprocesses in order to correctly handle the
"--without-c-locale-warning" case:
https://github.com/ncoghlan/cpython/commit/78c17a7cea04aed7cd1fce8ae5afb085a544a89c

If PYTHONCOERCECLOCALE=0 turned off the runtime warning as well, then the
behaviour of those tests would remain independent of the build flag as long
as they set the new environment variable in the child process - the warning
would be disabled either at build time via "--without-c-locale-warning" or
at runtime with "PYTHONCOERCECLOCALE=0".

The check for the runtime C locale warning would then be added to
_testembed rather than going through a normal Python subprocess, and that
test would be the only one that needed to know whether or not the locale
warning had been disabled at build time (which we could indicate simply by
compiling the embedding part of the test differently in that case).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Application support

2017-03-12 Thread Steven D'Aprano 
Hello Ryan,

Welcome!

My response is below.

On Sun, Mar 12, 2017 at 10:49:13AM -0700, Ryan James Kenneth Murray wrote:
> To whom it may concern,
> 
> I was about to use Markdown to verify or indicate any changes to the files
> when I was directed to c python and pep, however I have reached my
> abilities in understanding or contributing. I will have to broden my
> knowledge and insight into python. That is why I am asking for help in
> making sure that everything is satisfactory. As you can see I am concerned
> about entering anymore data

I'm afraid I cannot make head or tail of what you are talking about 
here. To be perfectly honest, your post sounds like something generated 
by a quite clever bot using a Markov chain to generate random text. It 
*almost* is meaningful, but not quite: there's a bunch of tech buzzwords 
(Markdown, C, Python, PEP) in some sentences which are grammatically 
correct but don't seem to mean anything.

What files are you changing, what data are you talking about, and what 
is "everything" that needs to be satisfactory? How is this relevant to 
developing Python?

If you are a bot, then you aren't welcome and somebody will soon remove 
you from the mailing list. (And I will feel silly for talking to you as 
if you were a person.) But in case you actually are a human being, I'm 
giving you the benefit of the doubt and allowing you the opportunity to 
say something that proves you are a human.

Thank you.


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Application support

2017-03-12 Thread Ryan James Kenneth Murray 
To whom it may concern,

I was about to use Markdown to verify or indicate any changes to the files
when I was directed to c python and pep, however I have reached my
abilities in understanding or contributing. I will have to broden my
knowledge and insight into python. That is why I am asking for help in
making sure that everything is satisfactory. As you can see I am concerned
about entering anymore data
Sincerely yours
Ryan Murray
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

2017-03-12 Thread Nick Coghlan 
On 12 March 2017 at 08:36, Jakub Wilk  wrote:

> This is a very bad idea.
>
> It seems to based on an assumption that the C locale is always some kind
> of pathology. Admittedly, it sometimes is a result of misconfiguration or a
> mistake. (But I don't see why it's the interpreter's job to correct such
> mistakes.) However, in some cases the C locale is a normal environment for
> system services, cron scripts, distro package builds and whatnot.


An environment in which Python 3's eager decoding of operating system
provided values to Unicode fails.


> It's possible to write Python programs that are locale-agnostic.
>

If a program is genuinely locale-agnostic, it will be unaffected by this
PEP.


> It's also possible to write programs that are locale-dependent, but handle
> ASCII as locale encoding gracefully.
>

No, it is not generally feasible to write such programs in Python 3. That's
the essence of the problem, and why the PEP deprecates support for the
legacy C locale in Python 3.


> Or you might want to write a program that intentionally aborts with an
> explanatory error message when the locale encoding doesn't have sufficient
> Unicode coverage. ("Errors should never pass silently" anyone?)
>

This is what click does, but it only does it because that isn't possible
for click to do the right thing given Python 3's eager decoding of various
values as ASCII.


> With this proposal, none of the above seems possible to correctly
> implement in Python.
>

The first case remains unchanged, the other two will need to use Python 2.7
or Tauthon. I'm fine with that.


> * Nick Coghlan , 2017-03-05, 17:50:
>
> While this PEP ensures that developers that need to do so can still opt-in
>> to running their Python code in the legacy C locale,
>>
>
> Yeah, no, it doesn't.
>
> It's impossible do disable coercion from Python code, because it happens
> to early. The best you can do is to write a wrapper script in a different
> language that sets PYTHONCOERCECLOCALE=0; but then you still get a spurious
> warning.
>

It's not a spurious warning, as Python 3's Unicode handling for
environmental interactions genuinely doesn't work properly in the legacy C
locale (unless you're genuinely promising to only ever feed it ASCII
values, but that isn't a realistic guarantee to make).

However, I'm also open to having that particular setting also disable the
runtime warning from the shared library.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com