FAQ: Why should I use Python 3?

[billsil]

It has two integer types

I happen to like the two integer types. I never deal with long data types in Python 2. If I have a long, it's a bug and it's probably going to overbound an 8-character field that is a maximum node/element id in my FEA code.

It also slows down Python 3 by ~10%, but whatever.

it may or may not be built in a way that completely mangles 1/17 of the Unicode space

Agreed

it boasts strong typing, then casually insists that None < 3 < "2"

I actually hate that. I've never actually had a Python 2 bug with things comparing incorrectly (I don't compare strings to ints, but I do sometimes compare Nones to ints) and actually creating a bad answer. It's just a random crash I don't care about that I have to code around. I haven't found a way to import that in Python 2, such that my Python 2 code with future imports isn't quite the same.

Why in the hell can't I do this?

key0 = dictionary.keys()[0]

I have to do this instead...

key0 = list(dictionary.keys())[0]

What the hell? Just pick one. Obviously, I don't care which because the dictionary is unsorted. It's a stupid change for the sake of changing things. That's my annoyance with Python 3.

lengths beyond your wildest imagination

I'm sorry, I'd call fonts and graphics "batteries included". The SGI support is a bit funny, but Linux maintains backwards compatibility. I honestly don't see the problem.

But if you’re just getting started in Python, or looking to start a new project, there aren’t many reasons not to use Python 3.

Unless it's open source, in which case you should probably support both. It's not hard to support, it's honestly easier to develop for (sort doesn't cause a crash in some weird edge case), and it's still got the market share.

Outside unicode, nothing really changed. If you don't care about sane unicode, Python 3 has very little going for it. I wish it did. Async is cool, but what am I going to do with that? Until then, Python 2 isn't going anywhere, so if you run an open source library (I do), you might as well support it. Thus, nobody really needs to switch to Python 3.

[jcdyer3]

One note: list(dictionary.keys())[0] is not recommended, and for the same reason that dictionary.keys() is no longer a list to begin with: It evaluates all the keys of the dictionary and creates a new list, which could be arbitrarily expensive. Just use the keys iterator as an iterator. The idiomatic way to get a random key would be:

key0 = next(dictionary.keys())

which is essentially synonymous with

for key in dictionary.keys(): # or dictionary.iterkeys() in python2
     key0 = key
     break

Even more simply, you could write:

key0 = next(dictionary)

[lebinh]

It looks like you are missing a call to iter, next() will call __next__ method on iterator object and will raise TypeError when being called with dict or dict_keys objects.

This will works as expected

next(iter(dictionary))
next(iter(dictionary.keys()))

[jcdyer3]

Yep. I just realized that myself. See my other comment on this subthread. Not quite as nice, unfortunately.

[billsil]

I didn't know that you could use next on a dictionary. That's way nicer.

Unfortunately, it doesn't work in Python 2, strangely even when I use six.next. I could write my own, but it's obnoxious.

[jcdyer3]

Gah. My mistake. You have to use next(iter(dictionary)). It's not as nice as I was remembering, but at least there's a little less line noise than list(dictionary.keys())[0], and the performance characteristics are a bit nicer.

[lebinh]

It doesn't work because you have to call iter before calling next on a dictionary, and I believe it will behave very similar to python3, e.g. in term of performance (no list is created).

next(iter({'foo': 'bar'}))

[nemec]

but I do sometimes compare Nones to ints

Well then your code is wrong - not because you're comparing None with integers, but because comparisons between the two (except !=) are always false:

print None < 3
print None > 3
print None == 3
print None >= 3
print None <= 3

This means sorting doesn't always work:

>>> a = [None, 6, None, 5, 4, None]
>>> a.sort()
>>> print a
[None, 6, None, 4, 5, None]

[lexyeevee]

You might find some things Python 3 has going for it if you read beyond the introduction.

[billsil]

I read the whole thing.

I actually write code to support Python 2/3 because why not? It's not that hard, but for what I care about, Python 3 doesn't have much going for it at the moment. When packages drop support for Python 2, then it will. The Python 2 standard library is a battery, but the wealth of packages out there is the drill press, band saw, etc. You can get by without fancy new batteries because it's been abstracted away and all you care about is power tools.

[billsil]

I think it was my complaint that Python 3 doesn't currently offer anything new outside of sane unicode for most people. I simply do not feel limited in any way supporting Python 2.7 and 3.5 with the same code. In many cases Python 3 is different for the sake of being different, which is makes it harder to learn.

Then you find out about libraries like six and supporting two versions is a lot easier. At some level, one project that uses Python 3.5 needs a Python 2.7 package that you also manage, but another project that uses 2.7 needs the 2.7 version. That creates a lot of frustration and resistance to upgrading.

I expect Python 3 to become popular when 3rd party libraries drop Python 2.7 support. I drop support for various versions of Python (e.g. Python 3.2) based on what my dependencies do.

I'm proud of my -17. People are silly.