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
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
> 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
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
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)
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
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
>
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
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
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
"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
11 matches
Mail list logo