Python 3 is killing Python

[Steven D'Aprano]

On Wed, 16 Jul 2014 08:52:31 +0300, Marko Rauhamaa wrote:

> Steven D'Aprano <steve+comp.lang.python at pearwood.info>:
> 
>> On Tue, 15 Jul 2014 23:01:25 +0300, Marko Rauhamaa wrote:
>>> In fact, I find the lazy use of Unicode strings at least as scary as
>>> the lazy use of byte strings, especially since Python 3 sneaks Unicode
>>> to the outer interfaces of the program (files, IPC).
>>
>> I'm not entirely sure I understand what you mean by "lazy use of
>> Unicode strings". And I especially don't understand what you mean by
>> "sneak". The fact that strings are Unicode is *the* biggest and most
>> obvious new feature of Python 3.
> 
> I mean that sys.stdin and sys.stdout should deal with byte strings. 

There are certainly use-cases for stdin and stdout to use bytes, but 
there are also use-cases for them to deal with strings. I'll certainly 
grant you that there ought to be an easy way to get access to the binary 
streams, but I think for a high-level language like Python, the default 
should be text, not bytes.

> I mean that open(path) should open a file in binary mode. Thankfully,
> the subprocess methods exchange bytes by default.

Likewise for files: by default, I should be able to do this:

open("foo.txt", "w").write("foo bar baz")

and have something sensible happen. Although I'm open to the suggestion 
that maybe the Pythonic way to do that should be:

print("foo bar baz", file="foo.txt")


Most programming languages I know of default to opening files in text 
mode, not binary mode, and I don't see any strong reason for Python to go 
against the tide there.

And I don't have an opinion on the subprocess module.


> To me, the main difference between Python 2 and Python 3 is that in the
> former, I use "..." everywhere, and in the latter, I use b"..."
> everywhere. If I should need advanced text processing features, I'll go
> through a decode() and encode().

Having len('λ') == 1 is not an advanced text processing feature.


[...]
>> As of right now, *new* projects ought to be written in Python 3.3 or
>> better, unless you have a compelling reason not to. You don't have to
>> port old projects in order to take advantage of Python 3 for new
>> projects.
> 
> But my distro only provides Python 3.2. What's wrong with Python 3.2?
> Why didn't anybody tell me to put off the migration?

Nothing is "wrong" with Python 3.2, except in the sense that it's now 
about 3 years old there are better versions (3.3 and 3.4) to choose from. 
If you're wedded to the idea of only using the version of Python that 
your distro supports, you may find yourself a version or four behind the 
latest release. (Red Hat only recently stopped supporting a distro where 
the system python was 2.3. Yay.)


-- 
Steven