Guido on Python

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

The only package I found that didn't work with our Python 3 infrastructure was Fabric, but that's really easy to spin out (and will be fixed soon).

There's really no reason to not use Python 3 for (almost) all new projects at this point. It's exciting! I expect engineers who're used to developing in Python 3 will start to feel embarrassed that they're still running 2, and we'll port over all of those internal codebases (like at Dropbox :P).

For me unicode was the reason to switch to 3, not everybody lives in an english-only world :-)

Of course, it is possible to install multiple versions side-by-side, and edit the scripts so they all start with #!/usr/local/bin/python3 or something like that, but it is just another barrier of entry. Not to mention that then there are most likely a bunch of additional modules that have to be tracked down to get something to work.

(Actually, come to think of it, this really isn't a python specific issue, this is really a general plea that if you are making something that is geared toward sysadmins, make sure that there is an easy enough installation method available for at least the currently supported versions of RHEL/Centos, Ubuntu LTS, and Suse Enterprise).

These days, I have few reservations about starting new projects with Python 3. It has become my new default.

I'm honestly not fond of languages like Rust that try to restrict mutability. The only one of the new breed of languages I've found that I really like is Nim.

A new language today shouldn't really implement Python metaprogramming, because Python already does that.

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.

    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.

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)

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.

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

    print "Hello World!"

    print("Hello World!")

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.

Lesson for language designers: never, ever mess with your debugging/printout facilities once you've hit the mainstream.

New Python fixed that.

Problems: 1) new Python wasn't very tolerant of real-world conditions where incorrect text encoding happens once in a while.

1b) there was great resistance to fixing that because "Python now did it correctly!" and the rest of the world was just assumed to do it correctly, always.

2) not everybody who already programmed in Python really understood the need for the new (and mostly correct) way of handling strings. Also not everybody in the US really understood Unicode and encodings.

3) there was no proper update path from Old Python to New Python.

4) it was not possible (or very difficult) to write code that was both valid Old Python and valid New Python and which did the right thing in both cases.

5) at the same time the interface for libraries written in C was changed.

5a) the new way was better.

5b) a change was needed for New Pythons string handling anyway.

5c) it could still have been done in a backwards-compatible way...

5d) ... but it wasn't, since the new way was Better.

6) lots of important Python libraries are partially written in C because pure Python is so slow

7) ... so porting all the important libraries was necessary for New Python to take off while at the same time being rather annoying and difficult work.

There were other changes at the same time that were improvements but which made upgrading hard. Print was no longer a keyword with lots of special handling and corner cases but an ordinary function. You could switch newer versions of Python 2.x to the same behaviour but not the older ones. Many libraries needed to work with many different Python 2.x versions, which made it hard to support Python 3.x at the same time. You could convert all your print statements to using a function that worked like the new print function and then either use that natively (3.x and newer 2.x) or provide a compatibility function that wrapped the print statement (older 2.x). You would put this code in a module you would selectively import depending on the Python version -- or some variant of that. Not actually hard but really annoying and something that required changing many lines of some libraries.

Ad 1, things have improved a lot and there are now known ways of fixing the remaining problems (with newer 3.x versions).

Ad 2, Unicode is better understood these days.

Ad 3 and 4, things have again improved. If you skip the first few 3.x versions and the early 2.x versions then it is not too hard to write code that works on both Old and New Python.

Ad 5, I don't know if is possible to support both ABIs in a single shared library, but at least the core code that actually does the work can be shared.

PyPy might have helped as well by making ordinary Python -- the kind you would otherwise write in C -- run fast.

Edit: formatting is hard.

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

For example I would never teach this in Python:

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

    for i in mylist:
        print(i)

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

    nums = list(range(10))

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

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

/s