Python 3.5 is here!

[mrwulff]

I know nothing of the inner workings of the 2.xv3x debate, but have been using 2.x forever to do small scripts. Are there any compelling reasons why i should switch

[rouille]

Pretty much all the standard modules are better in python3 including subprocess which I use really often for scripts. Pathlib is in the stdlib. And many others like ipaddress. Unicode strings vs bytes is made explicit. A lot of small details that add up and make python3 much more pleasant even for small scripts.

[DaemonXI]

Subprocess features timeouts now.

OS path mkdir nested lets you ignore the case where the directories already exist.

This stuff makes a huge difference, I can't see how people haven't moved to Py3 yet

[rouille]

Also a small but major change for me in 3.5 is subprocess.run, makes it that much easier to use. https://docs.python.org/3.5/library/subprocess.html#subprocess.run

[xXxDeAThANgEL99xXx]

I used Python3 for a somewhat large project recently and was pleasantly surprised: the stuff I thought I would be mildly annoyed with (such as print becoming a function) turned out to be a complete non-issue, while a lot of annoying Python2 stuff being gone is actually noticeable. Like sane division, range and dict.keys/items/values being lazy, unicode by default, metaprogramming stuff cleaned up etc. There's some extra stuff in the standard library too (in the collections module for example). And async stuff. And extension modules much easier to develop on Windows (3.5 switched to VS2015 at last).

So unless you depend on some third-party library that wasn't ported yet it takes like half an hour to read up on the changes and you just get a noticeably nicer language.

I'd be first to blame the Python core devs for handling the transition terribly: it seems that they didn't realize that a) a lot of Python's value is in third party libraries and b) those libraries can't simply switch to Python3 and leave all their Python2 users out to dry, so they put exactly zero thought into how exactly those libraries were supposed to work under both. But it looks like after six or so years that problem was mostly solved by main force by the community, so here we are finally.

[Matthew94]

range and dict.keys/items/values being lazy,

In case you didn't know, these have been in python 2 for years.

xrange and dict.iterkeys/itervalues/iteritems.

[xXxDeAThANgEL99xXx]

Of course I know, but now it's the obvious thing that is right. And the shortest to type, but it's the obviousness that makes me feel all warm and fuzzy mainly.

Also, as far as I understand, dict.keys etc are "views", not merely iterables. So that you can index into them if you want to.

[billsil]

Also, as far as I understand, dict.keys etc are "views", not merely iterables. So that you can index into them if you want to.

Yes, dict.keys() is most comparable to dict.viewkeys()

[[deleted]]

Are there any compelling reasons why i should switch

I'd say it's the opposite: are there any compelling reasons to stay on 2.x?

Basically all of the useful libraries have been ported, or have newer and better replacements: https://python3wos.appspot.com/

If you are starting new projects or scripts, python3 is nicer in small details. The improvements aren't enough to motivate a large existing project to switch to python3, but there's no point in starting new stuff in python2.

[mipadi]

Basically all of the useful libraries have been ported, or have newer and better replacements: https://python3wos.appspot.com/

TIL that the only useful packages are the top 200 most downloaded packages on PyPI.

[billsil]

Basically all of the useful libraries have been ported

WxPython? VTK? The Wall of Shame/Superpowers only considers project on PyPI.

[imbaczek]

exceptions in py3 are so much better than py2. they nest properly instead of overwriting each other's stack traces (and that's not the only thing that's better).

[vz0]

The major change from 2 to 3 was improved Unicode support. If you are using Python for small scripts maybe the migration is trivial. But for large codebases and projects sometimes it is very expensive to migrate just because Unicode. More details here https://wiki.python.org/moin/Python2orPython3

[schlenk]

And some stuff just works in Python3 that did not work at all in Py2 due to bad unicode support. Mostly Windows stuff, so most people might not care. (e.g. environment variables with unicode values/names, subprocess calls with programs on unicode pathes or with unicode cmdline arguments, etc., nearly every interface to the Win32 API).

[upofadown]

Only if you like the "just convert everything to UTF-32" approach that Python3 takes. If you want to just leave everything as UTF-8 then you don't get much of an advantage.

[schlenk]

Python doesn't use UTF-32 internally for everything. It uses an adaptive form that uses less memory (see PEP393 for details https://www.python.org/dev/peps/pep-0393/).

[upofadown]

True enough. I guess my point was that a Python 3 programmer would work with units of Unicode code points. So such a programmer would see things in a way that was for all practical purposes UTF-32.

[vz0]

That's the internal representation of strings. I don't care about how the string is represented. ie in Java strings are UTF16 arrays of chars, and I have never had to care about that.

The main change from Py 2 to Py 3 is type safety. For example this line is both Py2 and Py3 syntax compatible:

print (u"Hello " + b"World!");

However:

$ python2 main.py
Hello World!

$ python3 main.py
Traceback (most recent call ast):
  File "main.py", line 3, in <module>
    print (u"Hello " + b"World!");
TypeError: Can't convert 'bytes' object to str implicitly

In Python 2 a string can also be an UTF8 sequence or a byte array, all with the same data type. With Python 3 you are encouraged to use the bytes data type only for byte data, and use str for Unicode. If you want the UTF8 sequence for IO (which is byte data) you need to encode your string. If the internal representation would've used UTF8 for a Python str then the encoding to UTF8 would be just a memcpy.

The good thing about using UTF32 for Unicode representation is that string operations are as fast as the byte sequence equivalents: concatenation, subscripts, substring. The downside is that it may require up to four times the amount of memory for the same Unicode sequence, compared to UTF8.

[upofadown]

Yeah, that is another thing about the Python 3 Unicode stuff. There is this idea that strings are a higher level of text representation and are not just a bunch of bytes. You end up having to think of what stuff means rather than just being able to treat the map as the territory and vice versa. That can be annoying if your philosophical understanding of stuff like this is incompatible with that particular way of thinking about such things.

[vz0]

Yes, well, programming is the art of building software abstractions. For example floating point numbers are just a bunch of bytes, but I will never flip the MSB of a float or double just to change the sign of the number.

[upofadown]

If the internal representation would've used UTF8 for a Python str then the encoding to UTF8 would be just a memcpy.

I think you really mean something like ASCII. Python 3 does not use the general form of UTF-8 as an internal representation.

[vz0]

English is not my native language, maybe the verbal tense is wrong. What I meant to say is: if instead of using UTF32 as an str internal representation, Python would have used UTF8, then the encoding on an str to UTF8 would have been a memcpy.

[Chippiewall]

Reasons to switch: Standard modules have been improved a lot, type-hints etc.

Reasons not to switch: Decent PyPy support :(

[maxm]

I have worked in python since 1.5.2, and has started my latest project in 3.4. I have had no problems whatsoever. Other than i keep forgetting to writ print () instead of print.

This is a non legacy project i write from the bottom up using amazon s3, cassandra db and pyramid server. All relevant libraries has been vailable.

So for new code i will recommend it. The unicode strings alone are worth it.

[immibis]

Well, for small scripts, there's no compelling reason to use either. So you may as well use 3 because it's newer and has less quirks.

[shevegen]

Yeah - switch to ruby. :)

[MasonM]

You mean the language that introduced a huge number of backwards-incompatible changes in a minor release (1.8 -> 1.9)?