[Python-Dev] Python3 "complexity" (was RFC: PEP 460: Add bytes...)

[R. David Murray]

On Wed, 08 Jan 2014 19:22:08 +0000, "Matt Billenstein" <matt at vazor.com> wrote:
> I started in Python blissfully unaware of unicode - it was a different time for
> sure, but what I knew from C worked pretty much the same in Python - I could
> read some binary data out of a file, twiddle some bits, and write it back out
> again without any of these complexities - life was good and granted I was
> naive, but it made Python approachable for me and I enjoyed it.  I stuck with
> it and learned about unicode and the complexities of encoding data and now I'm
> astonished at how many professional programmers don't know the slightest bit
> about it and how horribly munged some data you can consume on the web might be
> - I agree it's all quite a mess.
> 
> So now I'm getting more serious about Python3 and my fear is that the
> development community (python3) has fractured from the user community (python2)
> in that they've built something that solves their problems (to oversimplify
> lets say a webapp) - sure, a bunch of stuff got fixed along the way and we gave
> the users division they would expect (3/2 == 1.5), but somewhere what I felt

I believe this is a mis-perception.  I think Python3 is *simpler* and
*less complex* than Python2, both at the Python language level and at
the CPython implementation level.  (I'm using a definition of these
terms that roughly works out to "easier to understand".)

That was part of the point.  Python3 is *easier* to use for new projects
than Python2.  I'm not speaking from theory here, I've written and worked
on non-trivial new projects in both versions.[1]

It is true that in Python3 you *must* learn the difference between
bytes and strings.  But in the modern world, you had better learn to do
that anyway, and learn to do it right up front.  If you don't want to,
I suppose you could stay stuck in an earlier age and keep using Python2.

It also is true that it would be nice to have a more convenient API
for, as Antoine put it, interpolating into a binary stream.  But
really, the vast majority of programs have no need to do that.  It
is pretty much only the low level libraries, most of them dealing
with data-interchange (wire protocols), that would use this.

> was more like a hobbyist language has become big and complex and "we need to
> protect our users from doing the wrong thing."

As I just learned recently, Python was always intended to be a "real"
programming language, and not a hobbyist language :)  But it was also
always meant to be easy to learn and use.

Python3's goal is to make it *easier* to do the *right* thing.  The fact
that in some cases it also makes it harder to to the wrong thing is
mostly a consequence of making it easier to do the right thing.

Python's philosophy is still one of "consenting adults", despite a few
voices agitating for preventing users from shooting themselves in the
foot.  But making "the one obvious way to do it" easy, and consequently
making the other ways harder, fits in to its overall philosophy just fine.
As does trying to prevent the wrong thing from happening *by accident*
(read: mojibake).

--David

[1] I also find it easier to maintain my python3 programs than I do my
python2 programs, probably because I've gotten used to the convenience
of the new Python3 features, and miss them when working Python2.

[2] With perfect hindsight I think we'd have focused more right from
the start on single-codebase, rather than on 2to3; but perfect hindsight
doesn't do you any good when it comes to foresight.