Re: [Python-Dev] Clarification of PEP 394 for scripts that run under Python 2 and 3

2015-11-15 Thread Nick Coghlan
On 14 November 2015 at 08:57, Barry Warsaw wrote: > On Nov 13, 2015, at 10:32 PM, Damien George wrote: > >>1. What is the true intent of PEP 394 when only Python 3 is installed? Is >>"python" available or not to run scripts compatible with 2.x and 3.x? >> >>2. Is it possible to write a shebang li

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread M.-A. Lemburg
On 14.11.2015 23:56, Victor Stinner wrote: > These encodings are rarely used. I don't think that any text editor use > them. Editors use ascii, latin1, utf8 and... all locale encoding. But I > don't know any OS using UTF-16 as a locale encoding. UTF-32 wastes disk > space. UTF-16 is used a lot for

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Raymond Hettinger
> On Nov 15, 2015, at 9:34 AM, Guido van Rossum wrote: > > Let me just unilaterally end this discussion. It's fine to disregard > the future possibility of using UTF-16 or -32 for Python source code. > Serhiy can happily rip out any comments or dead code dealing with that > possibility. Thank y

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Paul Moore
On 15 November 2015 at 16:40, Stephen J. Turnbull wrote: > What PEP 263 did do was to specify that non-ASCII-compatible encodings > are not supported by the PEP 263 mechanism for declaring the encoding > of a Python source program. That's because it looks for a "magic > number" which is the ASCII

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Guido van Rossum
Let me just unilaterally end this discussion. It's fine to disregard the future possibility of using UTF-16 or -32 for Python source code. Serhiy can happily rip out any comments or dead code dealing with that possibility. -- --Guido van Rossum (python.org/~guido)

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Stephen J. Turnbull
Random832 writes: > "Stephen J. Turnbull" writes: > > I don't see any good reason for allowing non-ASCII-compatible > > encodings in the reference CPython interpreter. > > There might be a case for having the tokenizer not care about encodings > at all and just operate on a stream of unicod

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Stephen J. Turnbull
Laura Creighton writes: > Steve Turnbull, who lives in Japan, and speaks and writes Japanese > is saying that "he cannot see any reason for allowing non-ASCII > compatible encodings in Cpython". > > This makes me wonder. > > Is this along the lines of 'even in Japan we do not want such >

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Jeff Allen
I'm approaching this from the premise that we would like to avoid needless surprises for users not versed in text encoding. I did a simple experiment with notepad on Windows 7 as if a naïve user. If I write the one-line program: print("Hello world.") # by Jeff It runs, no surprise. We may le

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Laura Creighton
In a message of Sun, 15 Nov 2015 12:56:18 +, Paul Moore writes: >On 15 November 2015 at 07:23, Stephen J. Turnbull wrote: >> I don't see any good reason for allowing non-ASCII-compatible >> encodings in the reference CPython interpreter. > >>From PEP 263: > > Any encoding which allows pr

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Paul Moore
On 15 November 2015 at 07:23, Stephen J. Turnbull wrote: > I don't see any good reason for allowing non-ASCII-compatible > encodings in the reference CPython interpreter. >From PEP 263: Any encoding which allows processing the first two lines in the way indicated above is allowed a

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

2015-11-15 Thread Random832
"Stephen J. Turnbull" writes: > I don't see any good reason for allowing non-ASCII-compatible > encodings in the reference CPython interpreter. There might be a case for having the tokenizer not care about encodings at all and just operate on a stream of unicode characters provided by a different