[Python-ideas] Normalized Python

[Andrew Barnert]

Chris, I pretty much agree with you, but there are two major additional points you didn't mention.

On Jan 29, 2014, at 6:33, Chris Angelico <rosuav at gmail.com> wrote:

> On Wed, Jan 29, 2014 at 8:11 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> 
>> 3. threat stdout/stdin streams as binary
>> why?
>>    because you don't want you data to be corrupt when
>>    you pass it in and out of Python via standard streams
> 
> Most definitely NOT. The standard streams should, by default, be text
> streams, and should have their encodings set according to what the
> other side wants.

Note that when the other side is a Windows console, what it _really_ wants is for you not to use stdio, but to instead use the separate UTF-16-specific console APIs.

Fitting this into Python 3's cross-platform io model is a bit challenging, and not yet done, but certainly doable. (It's been discussed multiple times, both on this list and elsewhere.)

Fitting this into a Python 2-style io model as Anatoly suggests is completely impossible. Instead, every single program would have to either check that stdout.isatty and platform is Windows and explicitly use something other than stdout, or figure out the console encoding (which is hard to do from inside Python if you take away the stdout.encoding that Python provides for the text stdout today) and explicitly encoding every string to be printed.

There's also the fact that the print function implicitly converts everything to a str for you, which wouldn't do any good if stdout were a binary file. Unlike Python 2, Python 3 has no way to convert arbitrary objects to bytes strings, which means you would need a mandatory encoding keyword arg on every call to print that took any args that weren't bytes-compatible.

Between these two issues, the proposal would effectively give Python 3 all of the stdio/print problems that Python 2 had, and more, without any of Python 2's partial solutions to those problems.