
Guido on Python - vezzy-fnord
https://lwn.net/Articles/651967/
======
napsterbr
I've been using Python 3.4 (and now 3.5) for development and couldn't been any
happier. The async features, specifically, are amazing.

When starting a new project from scratch, I see no reason NOT to use python 3.
Maybe if a few libs you depend heavily on are still not ported.

Even in that case, though, it might be a good idea to start on Python 3. First
because most libraries are already ported[1], and second, you could try
porting that specific lib, or maybe running it as a separate service using
python 2.

I guess the problem remains about maintaining big, Python 2-based programs.

[1] - [https://python3wos.appspot.com/](https://python3wos.appspot.com/)

~~~
zephyrfalcon
"""When starting a new project from scratch, I see no reason NOT to use python
3. Maybe if a few libs you depend heavily on are still not ported."""

wxPython comes to mind... :-/ Also PyGame, although it seems that there are
now development releases for 3.x.

~~~
Veedrac
wxPython largely[1] supports Python 3.

PyGame has worked on Python 3 for ages. Looking at [2] suggests it's from at
least since the start of 2012.

[1]:
[http://wxpython.org/Phoenix/docs/html/classic_vs_phoenix.htm...](http://wxpython.org/Phoenix/docs/html/classic_vs_phoenix.html)

[2]: [https://aur.archlinux.org/packages/python-pygame-
hg/](https://aur.archlinux.org/packages/python-pygame-hg/)

~~~
joshuapants
Pygame supports Python 3 in development releases. If you try to grab releases
from their site they're something like 6 years old.

------
fermigier
Two quick notes, probably well-known in the Python community, maybe less so
outside:

1\. The biggest hurdle to overcome when moving existing code bases to Python 3
(affectionally known as py3k) is third-party libraries. This is the main
reason why there is some pressure on library authors to move their libraries
to Python 3. Cf.
[https://python3wos.appspot.com/](https://python3wos.appspot.com/) for some
(very encouraging, IMHO) results.

2\. It's possible, in many cases, and without two much effort, to write (or
refactor) code that is compatible with both Python 2 and Python 3. One great
tool for this is the python-future project:

[http://python-future.org/](http://python-future.org/)

Cf. in particular: [http://python-
future.org/compatible_idioms.html](http://python-
future.org/compatible_idioms.html)

In some cases, it's even simpler. Flask, for instance, achieves it with a
small 55 LOC module:
[https://github.com/mitsuhiko/flask/blob/master/flask/_compat...](https://github.com/mitsuhiko/flask/blob/master/flask/_compat.py)

One last great resource is Lennart Regebro's book:
[http://python3porting.com/](http://python3porting.com/)

------
spinningarrow
"If you were to design a new language today, he said, you would make it
without mutable (changeable) objects, or with limited mutability."

~~~
bitL
In other words you'd make it slow without the ability to allow it to be fast.

~~~
gphil
> without the ability to allow it to be fast

Practically speaking, Python is still slower than a lot of languages that use
predominantly immutable data structures. I think you'd want to go to a systems
programming language for raw speed anyway.

~~~
bitL
Imagine immutable dict. How many programs in Python you know would still work?

~~~
tikhonj
Modern radix trees[1] can be as fast as the hash maps you'd find in a
language's standard library while providing additional capabilities (ie fast
ordered traversal). Making them immutable and persistent[2] is easy and only
adds a bit of performance overhead.

Obviously programs that rely on communicating by mutating parts of a
dictionary would have to be rewritten to use an immutable, persistent map—but
they could still maintain similar performance.

[1]: Namely "adaptive radix trees" as described in “The adaptive radix tree:
Artful indexing for main-memory databases” by V. Leis, A. Kemper, and T.
Neumann <[http://www3.informatik.tu-
muenchen.de/~leis/papers/ART.pdf>](http://www3.informatik.tu-
muenchen.de/~leis/papers/ART.pdf>)

[2]: A persistent adaptive radix tree in Java:
[https://github.com/ankurdave/part](https://github.com/ankurdave/part)

~~~
bitL
Thanks for the radix tree reference!

On the other hand, stating "they could still maintain similar performance" for
immutable dictionaries is misleading at best (you are right for dictionary
sizes approaching 0). Anyone can look up benchmarks on the Internet showing
real-world performance of immutable data structures and make their mind up if
they actually can deliver in their particular use cases.

Mutability could be _always_ used to boost performance on Von Neumann
architecture if you know what you are doing. It's just becoming impractical
due to increased complexity, pervasive security paranoia and the fact that
there are very few people that can get things done right. If you want to
contribute to advance your case, please create a competing computer
architecture as fast as Von Neumann's, physically possible, but based on
immutability.

~~~
semi-extrinsic
> Mutability could be always used to boost performance (...)

For the extreme case, see the EQUIVALENCE statement in old Fortran.

------
Animats
From the article: Von Rossum is still running Python 2.7 in production at his
day job at Dropbox.

~~~
shadowmint
His commentary starts at 12.38 in the video; it's really very thoughtful.

Here are some choice quotes:

    
    
        ...and why should you switch? 
        and ultimately, I'm not saying that you should switch.
        I would like you to switch... but I also recognize that it's difficult to
        switch, and it feels like a lot of hard work that you could also spend 
        instead on say, improving the design of your website, or adding features
        to your application.
    

but...

    
    
        So... python 3 is just a better language and it is getting better 
        over time.
    
        Python 2 on the other hand, is a fine language, and it will remain 
        exactly what it is. 
    
        Yeah, we'll fix the occasional bug, but its asymptotically approaching    
        2.7 perfect, and its never going anywhere beyond there.
    
        So, that's why you should switch to python 3, because the only way 
        to benefit from the good work the core contributors do, is by switching.
    

Seems reasonable to me.

Don't yell at people for using python 2; they have jobs and real like
commitments to do things like running a company that pays people.

...but if you _can_ use python 3, you _should_ because it's only ever going to
get better, while python 2 won't.

(and my apologies if I've transcribed that incorrectly, I did my best to
capture exactly what he said)

~~~
pekk
Why did you edit in the implication that Python 3 is not applicable for people
who have jobs and real life commitments to do things like running a company
that pays people? That is your opinion, not Guido's. Python 3 is already being
used in companies and it's plenty good enough for that. Including library
support. Dropbox using 2.7 is no different from Dropbox avoiding PyPy, they
are evidently ultra-conservative (and probably have a lot of old code they
don't want to port).

~~~
shadowmint
That is my opinion, my Guido's. That's why it's not...

    
    
        In Quotes
    

I'm not saying python 3 isn't suitable for production.

I'm saying (and this is _my_ opinion): If you have to use python 2, then do.
If you can use python 3, then do.

 _THIS_ is Guido's opinion:

    
    
        I would like you to switch... but I also recognize that it's difficult to
        switch, and it feels like a lot of hard work that you could also spend 
        instead on say, improving the design of your website, or adding features
        to your application.
    

...at least, I have to assume so, because _that 's what he actually said at
the keynote_.

So, take what you want from that, but don't accuse me of 'editing in' some
implication.

If you're happy using python 3; then be happy.

...but, if you shout at someone for using python 2, I think you're a douche,
because there are real life reasons some people keep using python 2.

...and I. And..., clearly, Guido, acknowledge that.

You don't have to. You can have your own opinion all you like... I honestly
couldn't care less.

------
RyanMcGreal
> There are also bugs that are feature proposals that do have patches
> attached, but there is a general hesitation to accept changes like that
> because there is concern that they aren't useful, won't mesh with other
> similar language features, or that they will cause backward
> incompatibilities. It is hard to take patches without breaking things all
> the time.

Obligatory: [https://xkcd.com/1172/](https://xkcd.com/1172/)

------
arturhoo
I agree with Guido that the thing I hate the most in Python is packaging in
general. I find Ruby's _gems_ , _bundler_ and _Gemfile.lock_ to be a much more
elegant solution.

On the other hand, I really like the explicit imports (when used properly).
Less magic that makes code navigation way easier.

~~~
davexunit
As a distro packager, I find Python's packages to be much better and easier to
integrate than Ruby gems. I've had no shortage of troubles with Ruby gems:
requiring on the git binary to build the gem (even in a release tarball), test
suites not being included in the gem releases on rubygems.org, rampant
circular dependencies, etc. Python's PyPI has caused me no such issues.

------
shadowmint
Why take someones word for it?

Watch the video and you can see what he actually said yourself;
[https://youtu.be/yCg3EMf9EYI?t=8m36s](https://youtu.be/yCg3EMf9EYI?t=8m36s)

~~~
acqq
It takes much less time to read an article. AFAIK LWN does a great job. Still,
thanks.

------
keithpeter
_" Dropbox has a lot of third-party dependencies, some of which cannot even be
rebuilt from the sources that it has. That is generally true of any company
that has millions of lines of Python in production; he also saw it at Google.
That also makes switching hard."_

Why can't these dependencies be built from the source _they have_ presumably
the same version as the currently build binary? Is it because other components
of the build chain have changed or what?

As a civilian, I found this situation mildly disturbing.

~~~
jofer
At least in my experience, it's very common for vendors to provide you with
the source (through a licensed agreement) but deliberately limit your ability
to build it. Sometimes this is through licensing, sometimes it's by excluding
some key portions of the build chain (e.g. internal libraries that don't
directly relate the the functionality of the software).

At any rate, at my current employer, we have lots of things where we have the
source as well as the libraries and headers, but don't have the capability to
build those libraries from source.

It sounds silly, but it's still vastly better than having no source access
whatsoever. At least for us, we often need to understand an implementation
detail of a proprietary library, but being able to actually build things is
secondary.

~~~
keithpeter
Good heavens - 'ransom strips'[1] in software. I had no idea.

Best of luck with it all...

[1] [http://www.rics.org/uk/knowledge/glossary/ransom-
strips/](http://www.rics.org/uk/knowledge/glossary/ransom-strips/)

------
atmosx
I never understood what kind of changes Guido made from 2.7 to 3.0 that kept
everyone off.

~~~
jvdh
There are both syntactic as well as behavioural changes.

A simple example is the print statement, in Python 2 you could do:

    
    
        print "Hello World!"
    

Whereas in Python 3 you have to do:

    
    
        print("Hello World!")
    

Now obviously, you can easily change this programmatically. Things get harder
when you use more advanced print statements, for example adding a "," at the
end to prevent a newline, printing to different targets, new ways of using
placeholders, et cetera.

Then there is the fact that strings are no more in Python 3, but they are
Unicode. Again for average strings that's not really a problem, but when you
start using bytes, special characters, et cetera.

There is a tool to translate programs from Python 2 to Python 3, but it does
not catch everything, and you still have to fix stuff manually.

~~~
acqq
Most of the common 2.x programs don't depend on the change in Unicode
semantics or whatever, but they really don't work simply because really
unnecessary changes in the way print and formatting must be written in 3.x. It
was technically possible to make much more programs still work while still
introducing the more convenient syntax and it was in my opinion bad judgement
not to do so.

In my view, those that made the decision took to seriously "there's only one
way to do it." Zen of Python actually says: "There should be one-- and
preferably only one --obvious way to do it." Even if the obvious way for 3.x
can be different from 2.x, I can't imagine any real-life effects from allowing
the alternative syntax for formatting and printing except for a few special-
case branches somewhere in the source. Yes, then the people would continue to
write it with the "wrong syntax" in the new programs too, so what?

~~~
eru
In Python3 print is now a function, and no longer a keyword. The syntax got
strictly simpler that way, and semantics, too.

You could try to make the interpreter guess when you want to use print as a
function and when as a keyword. But that would be horribly complicated, and is
bound to go wrong.

~~~
acqq
> But that would be horribly complicated

No it wouldn't. There would be some corner cases, but mostly it would just
work for the existing code whereas, from the perspective of the 2.x users, now
it just doesn't. I know, I write compilers for living. The maintenance cost
from the point of view of the compiler maintainer would almost invisibly
increase (there are much less trivial things to worry about) the benefit for
the current users would be significant. The reason it wasn't done is much more
"political" ("just one way to do it") than technical.

Specifically: once it's declared that _print_ is a function, you don't need to
treat the string print as keyword. Then you can notice comparing _print
expression_ and _print( expression )_ that _if you know_ that _print_ is a
function the braces aren't giving you any new information. So the difference
is do you want to encode the knowledge "print is a function" in the compiler
or not. That encoding is trivial, and even if it can be called "a special
case" isn't anything that anybody would spend any significant energy
maintaining. It obviously appears to be "less elegant" to describe your
compiler having "a special knowledge that print is a function" but there are
even ways out of that: you can generalize such constructs (function calls
without using the return value). But then "there would be more than one way to
do it."

But orders of magnitude more 2.x Python programs would "just work" when
started under a such 3.x. Of course, once you accept that the transition
should be less painful, you'd need provide the way for libraries to also have
the "newer" and the "older" ways to do it. "More than one way" is potentially
contagious. But, sometimes "worse is better."

~~~
eru
OK, as a litmut test, how would your proposed compromise Python variant deal
with the following program

    
    
        print
    

As Python 3, this program does nothing. As Python 2 it prints a newline.

I do agree that Python could have adopted the ML/Haskell syntax for calling
functions that does away with most parens. But I don't think anyone in Python
land would have swallowed that.

~~~
acqq
It's clear, in Python 3 that would have to behave as in Python 2 if our goal
were to have most of existing Python 2 programs "still working" when people
give them to Python 3.

------
stared
> Python 3 is a "much better language" than Python 2, for one thing. It is
> much easier to teach.

[citation needed]

I find it much easier to teach language, where range(5) _is_ a list
[0,1,2,3,4] rather than an iterator. Same thing for .keys() and .items(). For
people learning their first language iterators are not simple.

That said, right now I am teaching Python 3 rather than Python 2 (mostly due
to unicode and division). Though, I have mixed filling towards Py2/Py3
transition (it's not all web dev, where all serious projects are getting
ported; some projects are written only once and therefore changing to Py3
means letting them die).

~~~
agentultra

        I find it much easier to teach language, where range(5) _is_ a list [0,1,2,3,4]
    

I thought so too at first but I think it was because I dislike change. When I
really began to use Python 3 in earnest I came to like the idea because I've
almost never taken the value of range. And teaching loops without intermediate
variables is much easier.

For example I would never teach this in Python:

    
    
        for i in range(10):
            print mylist[i]
    

I would always teach this:

    
    
        for i in mylist:
            print(i)
    

Which is clearer and easier to read? Did I have to teach you the Iterator
protocol in order to understand that? No. It almost never comes up until
you're an advanced Python user.

In the rare case where I do need to take the value of range it becomes much
more explicit:

    
    
        nums = list(range(10))
    

If you're an old-time Python 2 user you might ask why you have to pass range
to the list constructor when it returns a list itself. But if you're a new
Python programmer learning Python 3 you don't have those expectations: range
is something you loop over and list is happy to do that for you. You could
also write it out long-hand:

    
    
        nums = [i for i in range(10)]
    

Which could be nicer if you wanted to transform the numbers or add some
conditional filters.

Over all I find Python 3 to be much more _consistent_ in its design than
Python 2 and thus _easier_ to teach.

~~~
stared
The problem is that:

\- object castings are not nice (for code brevity/clarity - things, which
Python aims to bee good at),

\- if objects are similar, it's pain to explain the difference (it's not a
thought - it's a thing I had to deal with many times).

In particular, if one is advanced programmer in general, or at least has a
firm grasp of Python basics, iterators are nice. But for newbies, they are
harder. (And it's even harder to hand-wave that they are "somethings, which
can be casted into lists".)

As a side note I dislike possibility of using tuples as iterables. It breaks
"There should be one-- and preferably only one --obvious way to do it." i.e.
using tuples in place where one (conceptually) should use a list.

And again, explaining difference to newbies is painful ("tuple is a
handicapped list").

~~~
agentultra
I think the real problem here is pedagogy.

I don't begin teaching someone programming by explaining objects and types.

I generally start by introducing three fundamental concepts: _variables_ ,
_conditionals_ , and _loops_. And I keep it simple to begin with:

    
    
        a = 1
        print(a) # 1
        a = 2
        print(a) # can you guess what it will print?
    

Then I add conditionals:

    
    
        if a == 2:
            print("it is two!")
        else:
            print("it is not two...")
    

And I only really cover 'for' at first:

    
    
        groceries = ["ham", "cheese", "eggs"]
        for item in groceries:
            print(item)
    

Along the way I explain some of the primitive data types: string, integer,
float; and containers such as list and dictionary. And that is usually enough
to get started with simple tasks. I tend to elide what functions are and just
call them "commands" until later on so that I can demonstrate why looping is
so cool:

    
    
        import turtle
        
        turtle.setup()
        
        for amount in range(100):
            turtle.forward(amount)
            turtle.left(75)
    

And that usually drives home the point: grouping commands together to repeat
them as many times as we wish using loops; variables hold data; and
conditionals let us do different things depending on whether something is True
or False.

I haven't had much trouble with this approach for years. I don't even get to
explain iterables to newbies most of the time! Once in a while someone tries
something like:

    
    
        a = "foo"
        a + 1
    

And they get TypeError or they pass in an object of the wrong type to a
function and get ValueError. Early on this usually isn't a problem because
some things just don't make sense like adding numbers and strings. However it
can get confusing when learning how to look up functions and use them because
we can only informally document what kinds of things a given function will
take in its signature... it's an advantage and disadvantage of the duck-typing
philosophy. It's a wart but one that I haven't really encountered with anyone
I've taught until they're pretty far along and able to help themselves.

------
estava
Feels like people will be urged to move to Python 3 due to the new features...
And yet I'm thinking that Python 4 will happen before many have been able to
move to Python 3. :-P

~~~
toyg
Because Python 4 will be only "whatever comes after the last 3.x", with no
backwards-incompatible changes, it won't matter: porting to "python 4" will
require the same effort as porting to 3. So start now ;)

------
dom96
I would really love to ask Guido what he thinks of the Nim programming
language.

~~~
icebraining
Well, he's on Twitter and G+.

------
wangii
python needs her alan cox!

