Python 2 or 3

[blaablaaguy]

I started learning python 2.7 (it was the version codeacadamy was teaching so i went along with it )a while ago last year and now ive kind of had a long break from programming and pi stuff. Ive started again and now I have no idea if i should carry on learning 2.7 or if i should start over and learn 3. Does anyone even use 2.7 anymore?

[Paeryn]

I started learning python 2.7 (it was the version codeacadamy was teaching so i went along with it )a while ago last year and now ive kind of had a long break from programming and pi stuff. Ive started again and now I have no idea if i should carry on learning 2.7 or if i should start over and learn 3. Does anyone even use 2.7 anymore?

Some people stick with it but for new projects you should really move on to Python 3. Python 2.7 is still around because there is a lot of legacy stuff that hasn't been updated to work under Python 3.

It's not a case of starting over with 3, the majority of stuff you've learnt for 2.7 is still valid.

[richrarobi]

I agree with Paeryn. Python 2 has an end of life (although they keep having to delay - some important features have also had to be backfitted) - but.... the documentation and libraries are better in 3. Everyone that tries to convert will put more pressure on the heeldraggers, eventually everything would be simpler...

I have had to convert a few things to python3 myself as the suppliers haven't (but I am a miserable git that likes simpler code anyway, so would probably do my own...) , also there are some conversions on github for some things.....

[blaablaaguy]

Okay looks like ill switch to python 3. Ill just skim though a python 3 tutorial untill i am where i am now with python 2 and pick up the changes like that.

[Michiel O.]

The changes aren't that big. print has become a function print(), instead of iteritems() you use items(), and strings are always unicode. Some names and modules in the standard library have been cleaned up. Oh, and of course there are some new features in Python3.

[Paeryn]

Also a big gotcha is that dividing two integers now returns the floating point division rather than an integer division (floor division). If you want Python 3 to do a integer division you have to explicitly do it using //

Python 2

Code: Select all

print 5 / 2  # prints 2

Python 3

Code: Select all

print(5 / 2) # prints 2.5
print(5 // 2) # prints 2

[bensimmo]

I started with python3 as I came to it with the Pi and their methods.

You'll have the advantage of knowing most of it already and be able to fix up old python code. I'm having to fumble through updating python2 code to get module to work.
Converting stuff to it's gets boring after a while.

That and IDLE3 nor Geany seem to have a nice step through code and looking at variables and such like, like I'm used to with even VBA in Excel.

[IanS]

There is only one reason I have found to stick with v2.x instead of moving to v3.x: speed. For some reason Python v3 is significantly slower than v2, by about 20% on the tests I have run.

[Michiel O.]

There is only one reason I have found to stick with v2.x instead of moving to v3.x: speed. For some reason Python v3 is significantly slower than v2, by about 20% on the tests I have run.

Care to share that test? I guess the devs will be interested.

[hippy]

There is only one reason I have found to stick with v2.x instead of moving to v3.x: speed. For some reason Python v3 is significantly slower than v2, by about 20% on the tests I have run.

Care to share that test? I guess the devs will be interested.

Any python code will demonstrate the issue -

Code: Select all

x = 0
for n in range(0,1000000):
  x = x + 1 

Code: Select all

pi@Pi3B:~$ time python speed.py
real    0m0.802s
user    0m0.740s
sys     0m0.060s

Code: Select all

pi@Pi3B:~$ time python3 speed.py
real    0m1.293s
user    0m1.110s
sys     0m0.030s

In viewtopic.php?f=32&t=146007 which was commenting on Python 3 slowness, I wrote; "From my own experience Python 3 is between 25% and 50% slower than Python 2 and similar has been reported by others". That was determined by running a variety of real world code I had written myself under Python 2 and 3.

There's a link in that thread I linked to above which seems to suggest slowness is down to the way ints and longs are handled but I also found that file input and output was also far slower.

[Michiel O.]

That's odd! When I time it on my system, I see Python 3 run faster than Python 2. This is a FreeBSD adm64 system, however, I must still test it on the Rpi. Could it be an ARM-related issue?

Code: Select all

(user@pasta) /home/user/prj/python $ /usr/bin/time python2 loop.py
        0.29 real         0.26 user         0.03 sys
                                                                                                              (user@pasta) /home/user/prj/python $ /usr/bin/time python3 loop.py
        0.22 real         0.22 user         0.00 sys

I wonder whether incrementing an integer by 1 a million times is a representative benchmark. Also, range() means something else in Python2 and Python3: in Python2, range() realizes a list, while in Python3, it returns an iterator-like object.

More investigation is needed!

[bensimmo]

How does xrange compare?

[Paeryn]

Python 3 can be slower because int is now an infinite precision integer (what used to be Python 2's long). Python 2's int was a native int (C's long so either 32 or 64 bit) but that isn't in Python 3 any more. Basically long got renamed int and the old int got removed, just like xrange and range.

Also, not too sure on this, but I think memory allocation / deallocation changed a bit (from 3.4) to better support multi-threading (synchronisation locks) so that might slow things down slightly too.

[Michiel O.]

I also was thinking along the lines of compilation. If your Python2 was compiled with optimisations (-O2 GCC option) and your Python3 wasn't complied with optimisations, wouldn't that make some difference? That could account for the 20% performance difference on all accounts (integer math, file I/O, floating point math, etc).

Maybe it's not even a CPU architecture difference, but just how the Python binaries were compiled and were included in the Linux distribution of your choice.

[hippy]

It seems to be more than compilation options. Some things in Python 3 do appear to be faster, but it seems the overall consensus for real world cases is that it is generally slower.

There was a recent discussion on benchmark speed comparisons on the Python-Dev mailing list -

https://mail.python.org/pipermail/pytho ... 46803.html

For many cases raw speed is not an actual problem; Python 3 is still responsive enough.

It is command line input-process-output applications where it can feel painfully slow. Once a Python 2 application takes a second or two the slowdown when using Python 3 becomes more perceivable.

A Python application taking a second when running on an X86 is tolerable, but that can be 4 seconds or more on a Pi 3B using Python 2 and even longer for Python 3.

[Michiel O.]

Thanks for the link, Hippy! That was an interesting read. Also interesting to see is that the python developers are really worried by this kind of 'performance regressions', especially the longer startup times. A few days later, I read this in another thread about the benchmarks:

I identified the regression, I created:

http://bugs.python.org/issue28637

It's a regression caused by:

https://hg.python.org/cpython/rev/223731925d06/
http://bugs.python.org/issue28082

The change added "import enum" in Lib/re.py. I propose to revert this
change for now, and discuss later a solution which doesn't impact
performances.

It's nice to see that my work of performance was useful to catch a
performance regression.

So they're working on it

[hippy]

So they're working on it

Though only in that case to remove slowness introduced between 3.5 and 3.6.

But that did make me realise the benchmarks compare 2.7 with 3.6, not the 3.4 which most Pi currently have available.

Python 3.0 was released at the end of 2008 so they have had eight years to optimise and improve performance, three years since 3.4 was released. I am not optimistic that we will see any major performance improvements unless someone does commit themselves to that task.

Given there is no single explanation as to why so many programs run slower using Python 3 it would seem likely there would have to be a lot of tweaks to optimise things to get a cumulative 25% speed-up.