On 15 November 2015 at 16:40, Stephen J. Turnbull <stephen at xemacs.org> 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-encoded form of "coding:" in the first two > lines. It doesn't rule out alternative mechanisms for encoding > detection (specifically, use of the UTF-16 "BOM" signature); it just > doesn't propose implementing them. That was my initial thought. But combine this with the statement from the language docs that the default encoding when there is no PEP 263 encoding specification is UTF-8 (or ASCII in Python 2) and there's no valid way that I can see that a UTF-16 encoding could be valid (short of a formal language change). Anyway, Guido has spoken, so I'll leave it there. Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4