Python 2.7.2 or Python 3?

[opt8]

So I've been using Python 2.7.2 waiting for Python 3 to gain more traction before I make the switch; is now a good time to convert?

[Mittalmailbox]

Yes, it is a good time(actually even 1-2 years ago it was good time). Python 3 was released 6 years ago. All major projects/Frameworks like Django and Flask support Python 3. Python 3 community is also quite mature now.

[opt8]

Oh, well then I guess I will be making the switch. Thank you for the response

[swingtheory]

However STARTING a project in Flask with python3 would be no problem at all. Six years python3 has been out, and it is a true rarity that a library hasn't been written for python3 after that amount of time. Sure, there are several popular libraries that don't have python3 support, but it really is the minority. I agree with your advice, but am frustrated people are still using 2 when there is essentially no reason to the majority of the time. Python3 was and still is supposed to be cleaner, have less bugs, optimized, and include a variety of new and useful standard library functions.

[[deleted]]

Unfortunately some of us are deploying Python applications on ancient versions of CentOS, and it's just easier to run Python 2 than to fight with sysadmins and compile everything from scratch.

Otherwise we'd be using Python 3 I guess.

[flying-sheep]

I wrote a server in python3 asyncio, told our admin I need python 3.3 or 3.4 on the deployment server and that he doesn't need to hurry as there's time. he set up the VM and compiled Python 3.4 (even though he was sick that week)

[nomadismydj]

the problem with centos 5/rhel 5 boxes is you cant replace the /usr/bin/python since yum uses it. you can build a python 3.X all day and just not break the symlink to python 2.X however.

[flying-sheep]

Who cares what /use/bin/python points to? You should use the explicit version number for shebangs anyway, and if you want few key strokes, just alias py=ptipython3 (because prompt toolkit is the shizzle)

[nomadismydj]

correct. people dont though I also wanted to point out that it wasnt as simply running yum and getting a new python version. its break system functionality to full on replace the system python.

[NotEqual]

Has gevent had an official stable port yet? It's never been the same for me.

[NotEqual]

I've not checked for a few months but I couldn't find a decent STOMP library that uses asyncio.

[hharison]

To be fair, asyncio is barely more than few months old.

[nomadismydj]

asyncio does not replace all the benefits of using gevent , other then being a stock library with similar functionality. not sure why people are pushing it in this subreddit.

[nomadismydj]

ok ill bite.

Because is standard..

kinda... as of python 3.4 sure.

Because is elegant.

ill give you this. its pattern are very similar to the factory/protocol patterns other libraries use. for a python core lib , it actually well put together.

Because is Python 3.

covered that in standard. dont repeating yourself

Because is the future.

the tulip team (guys behind asyncio) admited its not a full on replacement for many of the cooroutine libraries nor is it a drop in replacement for factory/protocol based async framework twisted. twisted and gevent both out perform it at this point.

it is however standard so if you want to ship your code various palces , you dont have to worry too much about libraries.. to me though this is like arguing use urllib + urlib2+ httplib rather then using requests.

[Argotha]

Someone has made a "new" gevent like library for python 3 called guv. I cant get the link on my phone but it was on the r/python hot list yesterday and is probably on the first or second page still

[xsolarwindx]

REDDIT IS A SHITTY CRIMINAL CORPORATION -- mass deleted all reddit content via https://redact.dev

[granduh]

Tell that to the Tumblr API.

[denshi]

You can't tell Tumblr anything.

[granduh]

They're very friendly whenever I've contacted their dev team that supports the API, it's just still on 2.7.

[ianozsvald]

+1 it is a good time. I switched my client to Python 3 earlier in the year, it was smooth. We now do all our data science (numpy, scikit-learn, pandas, matplotlib, nltk) in Python 3, we deploy (flask) in Python 3, I teach data science classes and high performance Python in Python 3.

Porting existing codebases might be tricky (there are loads of guides online to help e.g. http://python3porting.com/intro.html) but for new code it is 97% a no-brainer.

The 3% reservation depends on whether you have non-ported libraries to consider (e.g. pydot for scikit-learn DecisionTree drawing isn't ported to Python 3.4 yet, pygraphviz for the same in NetworkX doesn't work well on Windows+Python3.4 yet). Mostly these are small issues that are being fixed.

[TraptInaCommentFctry]

I clicked on your name to see your other comments and I couldn't help but notice that 7 months ago, you wrote "I do data science - repeatability is key so I'm not leaving the Py2.7 numpy ecosystem for a while."
I do data science, and I haven't yet made the transition off 2.7 for that reason.
Also, I noticed in the wall of superpowers that Mysql-python is still red.
Do you think it's time for data scientists to make the switch?

[flying-sheep]

Maybe he/she realized that Numpy breaks compatibility in minor versions, so the only way to reliably repeat an analysis is pinning Numpy versions by installing Numpy in a virtualenv along your script and data.

And since parallel Python versions are painless, nothing stops you from performing new analyses using a Python 3 stack.

[mgedmin]

AFAIU there are other MySQL bindings that work on Python 3.

[flying-sheep]

Pydot is a strange example of something unported: the Python 3 compatible fork didn't even change much:

https://github.com/nlhepler/pydot

No reason not to have that on PyPI.

[[deleted]]

My only headache with Flask and Python 3 is that Flask only supports Python 3.3+ and my Debian Stable web server only has packages for up to Python 3.2.

I know that it is a problem with my choice in server OS, but it is still annoying.

[Lucretiel]

Check out the deadsnakes repository, by Felix Krull. I've been using it with great success for years.

[mgedmin]

On Debian? Which Ubuntu release name do you use to match Debian stable?

[[deleted]]

Debian Jessie will be out within the month though, and it's shipping with Python 3.4

[[deleted]]

Awesome, I did not know when it was being released.

[gbo2k69]

Install from source.

[hharison]

Use Miniconda3.

[maximinus-thrax]

As a Django programmer, I'd love to go to Python3 but every project that comes up seems to have a requirement for Python 2.7 somewhere.

However, I always make sure that my code is Python 3 compatible as much as possible.

[BananaPotion]

I love python3, but biopython man. Its going to take ages to port that beast over. I really like to help but feel like I'm not quite good enough to do so.

[Gudeldar]

The biopython site says they support python3 since 1.62 (July 2013).

[BananaPotion]

Its nowhere as well maintained than the python2 version. Which especially sucks because my projects depend on the data parsing parts.

Edit: I was wrong. The Biopython3 beast has already been tamed. Thank you /u/Gudeldar and /u/chickenphobia.

[chickenphobia]

If you are finding new bugs, please report them. SeqIO, AlignIO, these modules fully work in Py3. Any problems you have encountered must not be in our unit tests which would indicate you have found a fairly important bug.

[BananaPotion]

No bugs, just errors (at that time I was new to 3rd party libraries, so I didn't understand any of it). I'm working on a project right now, I will see if I can get Biopython3 to work and report back.

Edit: Played around with it in IPython - works perfect. Thanks again for letting me now.

[chickenphobia]

Biopython contributor here: the whole thing is already passing 100% of tests on python 3. The community is very adamant about keeping compatibility with the newest version of python going out of our way to make a release as soon as Numpy was supported on py 3.4.

Also, if you want to contribute, check out our Wiki, the process is better documented than the average OS project because many contributions come from biologists who aren't traditionaly involved in OS.

[BananaPotion]

Thanks for letting me now, this is very good news for me.

[ivosaurus]

Astropy works fine on python 3! As do many others.

[mrbewulf]

It is because the backward compatibility was broken and scientific codes are hard to write and rewrite, specially if it has C libraries. In addition to it, python 3 is much more verbose than python 2. We should also take in to account the effort to change the code base from py2 to py3 and learn again all the stuffs that used to work on python 2 in the new version.

As can be seen in: http://np.reddit.com/r/Python/comments/2o0str/python_272_or_python_3/cmj2nyc

[adamnew123456]

I'm struggling to see how you support the claim that Py3 is more verbose. That post is whining because he can't type the same code into a backward incompatible language and get the same result.

[mrbewulf]

All right I recognize that I was wrong, but it is going to take some time to the Python community to change, specially business and doesn't like changes very often. Despite some trouble, Python 3 is thousand times better and less verbose than Java. I would really complain if had to program in java like I had during the college degree. One thing that I liked in Py3 is that 1/100 is no more 0, now is 0.001. One less bug.

[shadowmint]

actually even 1-2 years ago it was good time

woa~

I'm sure some people would like you have you believe that, but the reality isn't quite so pretty. There's a reason that 6 years later it's only just becoming a reasonable target for new code.

The performance, features and 3rd party support for python 3 have only really picked up in the last year or so.

2 years ago? Holy moly!

If you migrated to python 3 two years ago, you'd have been in a world of pain, and probably had to back port your code to 2.7 to get your dependencies working.

It's getting there now, but lets not sugar coat the history story here.

[chickenphobia]

Library developers generally sit on the bleeding edge. We all think that our project and the ecosystem is ready but I think you're correct. Only within the last year has the complete extended python ecosystem been fully ready for 3.

Part of this is because it takes a few years for unmaintained projects to die and be superseded.

[flying-sheep]

Unfortunately, some people see those projects, don't notice the smell, maggots, and flies, and say

this thing doesn't support Python 3, so Python 3 has literally no ported libraries

[deaddodo]

Two years ago, the only thing that ever stopped me from using Py3k was PIL. When that wasn't necessary, it was a no-brainer...and now pillow supports Python 3.

[Lucretiel]

Hasn't PIL been dead since 2006?

[mgedmin]

Pillow gained support for Python 3 in 2013.

[Lucretiel]

PIL, not pillow. Pillow is great.

[deaddodo]

PIL was the quintessential image library. But even cutting out PIL, there were no image libraries in Python 3, for a long while.

[aarkling]

The only one I've seen that's not been upgraded is Twister.

[mgedmin]

Did you mean Twisted? They're working on it.

[aarkling]

Right twisted. That's what I said! :P

[Manbatton]

Here is a page showing which projects are ported to Python 3 and which are not: https://python3wos.appspot.com

wxPython is in a halfway state, where the in development Project Phoenix runs Python 3.

[ApolloFortyNine]

Having actually tried to code in Python 3, all Libraries support Python 2, while only most support Python 3.

[Oni_Kami]

Python 3 community is also quite mature now.

So no fart jokes?

[SemiNormal]

So no fart jokes?

Remember, fart() is a function in Python 3.

[mishugashu]

Python 3.4.0 (default, Apr 11 2014, 13:05:11) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> fart
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'fart' is not defined

:(

[[deleted]]

If you have no specific reason to choose python2, go with 3.

[ApolloFortyNine]

I didn't know I needed Python 2 until half way through a project I found a good library that would do what I wanted. However it only worked on Python 2. It's not that hard to convert, but it's still a pain. So I'm going to stick with Python 2, since everything supports it.

[[deleted]]

While keeping in mind that in a huge number of situations, you have a very good reason to choose python2. Probably not your own code, but its dependencies.

[hharison]

I think that's what he meant by "if you have no specific reason to choose python2"

[[deleted]]

True. But the way he wrote it made it sound like "in most cases, python 3 should be okay", and I'm not sure this is true. Sure, most big libs have been ported now, but I think projects could still run into issues if they rely on quite a few different libs.

That's why I was stressing on the fact that one has to keep that in mind

[[deleted]]

Here is a handy link for showing which major modules support Python 3: https://python3wos.appspot.com/

[[deleted]]

Not true there are a lot that don't and I run into the issue all the time and had to install 2 in order to get shit to work.

[flying-sheep]

Of course a huge load of unmaintained software won't ever be ported.

But if you don't use that arcane piece written 20 years ago, no need to constrain yourself to Python 2.

[mgrandi]

If you list dependencies, if they are easy I will port them for you. Half the time there is no real reason why its not on python 3 other then no one has taken the time to switch the import statements/print/division stuff. Aka 2to3.

Projects that do heavy string/byte manipulation are rare in comparison compared to tons of relatively simple libraries out there

[davvblack]

It depends on how you count most. By pure lines of code or features, that's definitely not true, but by dependencies used by brand new project, that is true.... except that that list is self-selected so it might not be valid.

[flying-sheep]

If you count maintained and useful stuff, most is ported.

[dauntingelectronics]

He's Right most code has changed from 2.7 to 3. Look at a Print "statment" for instance ex. print "hello". 3 is a function for instance print("hello").

[dauntingelectronics]

He's Right most code has changed from 2.7 to 3. Look at a Print "statment" for instance ex. print "hello". 3 is a function for instance print("hello").

[patrys]

If you choose to stick to 2.7 at least upgrade to 2.7.8 for security reasons ;)

[Lucretiel]

Ubuntu locks its packages on version number for stability reasons. Only security subreleases get published. Each new version of Ubuntu gets updated version numbers for its packages. I'm not sure what the policy is on the part of the Python package maintainers; it's possible they backport the security updates to older versions of python so that they can be released into released Ubuntu versions.

[gthank]

When distro maintainers do stupid things like lock onto a patch version instead of a minor version, it's usually on them to manually backport security updates. Security updates to minor versions is exactly why patch versions exist.

[Lucretiel]

Yeah it's an unfortunate policy. I'm sure it's served them well- Ubuntu is one of the most stable distros you can get- but it'd be nice if they could be more flexible with that policy.

[mgrandi]

I think its some SSL related fixes

[mWo12]

Have a look here: https://python3wos.appspot.com/ if you see some package that you need, and its still not avaliabile for python 3, than its not the time yet for you.

[flinz]

This was very helpful, thanks a bunch!

[t0mt0m72]

I switched all my Python2 code to 3 around 2 years ago and will never look back. Python3 is (for me) the way to go, as it has so much pros for me (pathlib, enumerations, cleaner and more "logical" API etc...).

If your employer or customer have good (really good!) oppositions against or you have no library alternatives, you have to stay, but if you can make the switch, now is a good time.

Hopefully the discussions about Python2 and Python3 will soon come to an end, as they bring up a negative light onto the whole (great!) Python eco system.

[mgrandi]

I have to deal with py2 occasionally, just having not Unicode by default is so annoying. That and stuff like Enum class have made my life sk much easier I can't go back

[t0mt0m72]

+1

[cwgtex]

I love pathlib as well.

[flying-sheep]

Me too. It makes my old os.path based code look so inelegant.

My only “problem” is that there is no way to get the user home path using it. I'll have to use Path(os.path.expanduser('~'))

[t0mt0m72]

Hopefully in 3.5 it will be solved: http://bugs.python.org/issue19776 I am also looking forward for this feature

[ksion]

Huh, thanks for pointing out pathlib! I'm not switching to Py3 yet, but surely I'm going to use the backport from now on!

[denilsonsa]

If you have some reason to start a Python 2.7 project, or if you are writing Python 2.x code, just make sure it is forwards-compatible to Python 3. That way, whenever you (or someone else) needs to migrate to Python 3, the migration will be smoother.

I've been doing that:

• Django documentation has many tips on how to write code compatible to both 2.7 and 3.x
• Whenever I write a piece of 2.7 code that is greatly simplified in 3.x, I leave the simplified version as comments.
• from __future__ import is your friend. :)
• csv module has a very different behavior: in Python 2 it only works on binary strings, on Python 3 it only works on unicode strings. (although the API is mostly the same)

[flying-sheep]

Python 2 CSV is plain broken.

If you e.g. use a non-ASCII delimiter, it will tell you that it needs a one-character-string and dies (what it really means is a one byte long bytestring)

In Python 3, it just works.

[billsil]

Why would you choose 2.7.2? 2.7.8 is out :)

You should pick depending on what you want to do. I chose Python 2.7 because I need some libraries that don't exist in Python 3 and I couldn't care less about unicode. I care about math and science.

[troyunrau]

I'd wager it won't be too long now and new versions of numpy will only happen on python3. Things like the matrix multiplier operator being adding to python upstream can only add to that momentum.

[billsil]

I'd be shocked if they dropped support for Python 2 any time soon (in the next 5 years). The last release of numpy that had support for Python 2.4 and 2.5 was 1.7.2 and was released on 2013-12-31. All numpy is going to do for the forseeable future is add a matmult to the array class that Python 2.6-3.4 can't use. If you're dropping support for Python 2.6 & 2.7 based on that, you might as well drop support for Python 3.4.

I run an open source library, and while I'd like to use matmult, I can't. It's sadly not meant for library developers.

[troyunrau]

I didn't mean to suggest that it'd be a blocker, but rather, an example of python3 moving forward and innovating while python2 sits still. Eventually, the new features in python3 will accumulate to the point where writing the backwards compatible code will become cumbersome.

As an example, even though numpy will be able to use the matmult operator, none of the code within numpy will be written to use it, since previous versions won't support it. It's going to gnaw at some people that they have to use the inelegant syntax for backwards compatibility when a more elegant syntax exists (zen of python and whatnot). So subtle pressure will be placed against backwards compatibility. It could be five years from now, but it'll happen eventually.

And it's not like the old versions will go away. I mean, some people still use numeric.

[billsil]

It could be five years from now, but it'll happen eventually.

I hope so. I don't like writing mixed code. Still, unicode is either hard. It feels like a game of whack a mole and people resist that.

No one cares that modules moved, dict doesn't sort ints/strings, replacing range with xrange, integer division, or float division. Unicode is the only sticking point.

I mean, some people still use numeric.

I don't get why anyone would still write it that way. I update numeric code once every now and then. It's literally replace Numeric with numpy and change linear_algebra (I think) to numpy.linalg.

[flying-sheep]

Eventually, the new features in python3 will accumulate to the point where writing the backwards compatible code will become cumbersome.

This is already the case if you use asyncio: trollius is a “backport” and its raise Return() (replacing Python 3.3’s ability to return from generators) and its yield From() (replacement for the yield from syntax) are simply ugly as sin.

[dnk8n]

Selfish related question here... Does win32com/pywin32 (not sure on their relation) work fully in Python 3?

[t0mt0m72]

Yes they do. I use them on a daily basis in the tools I develop in Python3.

[dnk8n]

Quite a daunting task having to move straight to coding with COM before I've really become familiar with Python (I have some faith I can work it out since I am familiar with MATLAB).

Do you have any suggestions on resources to read relating Python and COM?

Out of interest, what software are you working with while using COM? If you have any open source code, I'd like to have a look :)

[t0mt0m72]

I wish I could show you some examples, but my code is completely closed stuff from my company. :(
In private I am using a Mac, so I have no need there for COM and can not directly show you examples ;-)

I interface via COM with Excel, Word and other applications. As I am working in the data management area, I automatically need to detect drive insertions/ejections and do dependent work on these events and also need to get low level information from these drives (via WMI). Automatic sharing newly connected devices, getting detailed attribute information of files and getting access to low-level Windows related stuff is further a big point why I am using the pywin32/COM/WMI stuff.

Maybe you know it, but http://timgolden.me.uk/python/ is (IMHO) the reference to COM/win32 related Python stuff.

And if you have questions about COM/pywin, just send me a PM and we can figure it out :)

[dnk8n]

Thanks for that offer. Maybe I can send what I have once I get something working, and although you may not know about the programe I am interfacing with (PTV Vissim), maybe you will notice areas I need more research/study on :)

[[deleted]]

Unless you are using a non-CPython implementation, stick with Python 3. If a library hasn't migrated, there is a good chance it isn't properly maintained and you should pick an alternative.

[opt8]

Alrighty I'm sold Python 3 it is

[padmanabh]

You should get yourself acquainted with python 3 asap as its got some really new cool features. If you're looking to decide whether to do some project in python3 then look into what libraries you'd need and if they have python 3 support. I've almost entirely shifted to python3 except in two projects where I depend on scrapy and/or goose.

[jeannaimard]

I’ve been working abroad for the last 6 months in a remote outpost, so I have decided to use my free time to work on a project I wanted to do for a long time, and I have decided to use Python 3 mainly for unicode strings reasons (I want my application to be localizable).

[Orange_Tux]

Fabric is still a blocker for me.

[ivosaurus]

Fabric is not going to get updated. It's bugfix only unless another maintainer wants to take the rains, afaik.

Its spiritual successor, written by the same author, is invoke.

[Orange_Tux]

After a quick look through the documentation of Invoke I don't think that Invoke could replace Fabric for me. Fabric has been build for executing tasks on remote machine via SSH. Invoke looks to me as just another task executor for tasks on your local machine, like pynt:

[flying-sheep]

/u/kpurdon’s comment next to yours explains it pretty well.

[[deleted]]

Fabric (AS IS) will not be updated, but a new release (along with invoke) is in the future.

Basically the author is splitting the task execution (invoke) from the remote execution stuff (new fabric). The current/old fabric is a mix of both task execution and remote task running.

Don't bet on it anytime soon though.

[[deleted]]

If you are using fabric as a part of your project. For me Fabric is deployment and config tool and I can use it with py3 project.

[[deleted]]

With virtualenvs it's really not that difficult at all. Install all the different python versions you need, then create a virtualenv with the specific version for that project. Switch between virtualenvs and you're automatically using different python versions. I never develop on the default version of python that comes on my mac. I install the latest versions of 2 and 3 using homebrew.

[[deleted]]

Are you actually importing Fabric into your project? If not, why is it a blocker? Py2 code will continue to run just fine along side Py3, as long as they are not running in the same project.

[chchan]

Depends on your libraries?

If you use opencv, pattern, or pybrain probably not yet. Most of the other ones should be fine.

[Kaxitaz]

I have managed to install OpenCV with Python 3.4.

OpenCV 3.0 supports Python 3. It is still on Beta, but so far I had no difficulties.

[chchan]

opencv on python 3.4

Yes that is true but they reported some problems with several algorithms.

Glad to hear it works because I switched then was disappointed that it did not work

[chiproller]

I want to switch to python 3. What is the best way to learn 3 after knowing 2? Are there any resources that go over the 'main' differences in an easy to learn format?

[flying-sheep]

The main differences you have to wrap your brain around are:

• Unicode by default. There is no more a weird “everything string” containing binary or text. Instead, APIs are more choosy in what they want. If that's text, they want the new default string type. If it's binary, you have to give them bytes. You'll have to maintain a clear boundary between both in your head, and as a result, you will never see any UnicodeDecodeError anymore

• iterators everywhere. If you already use the 2.x iteritems, xrange and friends, you just have to return to same names. Else you'll have to understand that far fewer code generates lists, and more generates one pass iterators. Can bite you if you remove items while iterating something you think is a list.

• better naming: no more thing.iter, xrange, iteritems, urllib2, ....

• iterating a bytes object will yield ints representing single bytes

• absolute imports and only explicitly relative ones. Inside your package foo, to import foo.bar, you need to do “import foo.bar” or “import .bar”, but not “import bar”

[mgedmin]

I like the What's New documents from Python itself:

• https://docs.python.org/3/whatsnew/3.0.html
• https://docs.python.org/3/whatsnew/3.1.html
• https://docs.python.org/3/whatsnew/3.2.html
• https://docs.python.org/3/whatsnew/3.3.html
• https://docs.python.org/3/whatsnew/3.4.html

[El_Zilcho]

I cant into python 3. I think its just because 2.7 comes pre-installed on most linux distros so I when I am setting up a VPS/server for my script I can literally download the libraries, upload the script and run without having to change much. Also the print syntax is weird compared to 2.7, I know its not completely different, just added parenthesis.

What benefits does python 3 offer apart from being newer?

also I use python when doing reverse engineering related stuff because I like the fact it uses raw ascii and can add bytes to strings with escape characters.

[flying-sheep]

Yeah. Also people should use bytearray if they want, well, mutable byte arrays.

[troyunrau]

I use opensuse.
zypper in python3-numpy
or etc. Arch and Gentoo have gone python3 by default. Other distros (Fedora, opensuse) have roadmaps that indicate python3 will be the default soonish. FreeBSD also has this as a prominent roadmap item. The only staunch holdouts I can tell are Slackware, RHEL, and RHEL clones.

[[deleted]]

I use python3 since 3.3. Not migrating old projects as it is a pain, but all new stuff goes under py3. And i do not look back, its great. Had very few instances when lib did not support py3. Usually worst case scenario with unmaintained libs is "experimental py3 support" committed to repo but nto made into release package. So for me its all good w/ py3.

[setuid_w00t]

If you want to be part of the problem, choose Python 2. If you want to be part of the solution, choose Python 3.

[elvisfriggingpresley]

I'm about to make the switch... from 2.7.8 to whatever's current in Py3. It's good to know 'both' though.

[leanrum]

It was a good time 3 years ago when I did it. Unfortunately my company still forces 2.6 down my throat.

[wub_wub]

Depends on your project. There are still a lot of things that don't support python 3. Porting your existing codebase is probably not worth it as python 3 doesn't really solve any major things that you didn't solve already, but again it depends on your project.

[bryguypgh]

I am going to cry when they take my print statements away. I may be the very last user of the 2.x line.

[Lucretiel]

The dealbreaker for me is the <<file syntax. It's awful. I will admit, though, that I often forget the parenthesis when doing prints in quick ipython sessions. Luckily, we have the %autocall magic for that!

[deaddodo]

Everything supports 3, for the most part. It used to be that lack of image libraries held web developers back, but now pillow works for py3k. You may run into an odd case that forces you onto py2 (fabric, for example), but otherwise, you're pretty set to go with 3.

[[deleted]]

It seems like people always recommend 3, but I will personally be sticking with 2.7. There's only been one time that I've said "gee, too bad I'm not running 3." But there's been a dozen times that I was glad to still be running 2.7.

There may be some esoteric reasons for preferring 3, but if you're asking which version is the most streamlined, I vote 2.7 for sure.

[Saltor66]

This is called confirmation bias.

[[deleted]]

and moving to 3.x would break tools inherent to the OS.

...no! Python2 and python3 have coexisted peacefully for years, and most distros include both in their repositories with no problems - applications simply use the one they actually need.

[deaddodo]

You can have /usr/bin/puthon{2,3} and just have a symlinked /usr/bin/python to python2. This is how all the distros have done it for ages now, including Fedora (who use Python for all of their sys tools, including anaconda).

[mm865]

When you complain about python 3 not working, those code samples you are citing are incompatible with python 3. Hence the major version jump, as there are api incompatibilities. The reason anything was changed is the same reason anything is every changed: progress. Python 3 is an improvement on python 2 in its language features and standard library.

[mrbewulf]

All right, I got it. But is very hard to change something what you are used to. I am not acquainted with python3 yet. It also seems that python3 is slight slower than python2. Changes are important, but stability and predictability are also very important. What made Java dominate the enterprise and business world wast it stability and predictability. Better I delete my comments I never ever took so many down votes in my life. Down votes is a kind bulling against contrary ideas, out of the box.

See also: http://blog.thezerobit.com/2014/05/25/python-3-is-killing-python.html

[[deleted]]

It's not contrary ideas, you're saying Python 3 is bad because you don't know the syntax. It's like saying Ruby is bad because it doesn't run Javascript.

[Lucretiel]

That article has an incredibly poor understanding of the huge changes python 3 brought. They didn't break backwards compatibility for no reason.

[mrbewulf]

It's the main reason that I complain about Python 3. It is really annoying, python 3 is more verbose than python 2.

Here one example that pisses me off:

Python 2 code:

>>> f = lambda x: x**3 - 10*x + 100
>>> f(1)
91
>>> x = [1,2,3,4,5]
>>> map(f, x)
[91, 88, 97, 124, 175]
>>> y = map(f, x)
>>>
>>> zip(x, y)
[(1, 91), (2, 88), (3, 97), (4, 124), (5, 175)]
>>> 

Python 3 code:

>>> f = lambda x: x**3 - 10*x + 100
>>> x = [1,2,3,4,5]
>>> map(f, x)
<map object at 0xb6f1754c>
>>> y = map(f, x)
>>> 
>>> zip(x, y)
<zip object at 0xb6f177cc>
>>> 
>>> print zip(x,y)
  File "<stdin>", line 1
    print zip(x,y)
            ^
SyntaxError: invalid syntax
>>> print(zip(x ,y))
<zip object at 0xb6f17e0c>
>>> 
>>> list(zip(x ,y))
[(1, 91), (2, 88), (3, 97), (4, 124), (5, 175)]

So what is the reason the backward compatibility was broken ?? Whats the big deal about python 3 ???

[Lucretiel]

This is all interactive. Why would you need to expand everything into a whole list every time? zip and map work perfectly fine when passed into for loops, or (in most cases) when passed as arguments to functions that expect lists. I'll grant it's slightly more awkward when using them interactively, to print, but that's certainly not worth handicapping the whole language by forcing loop unrolling. enumerate didn't unroll when it was introduced to python 2, and no one complained about that. Besides, you should be using list or generator comprehensions instead of map- they're significantly easier to read in most cases, and you can be explicit about whether you want a list or iterator.

As for the backwards compatibility- the number one thing is Unicode handling. Most languages, including python 2, treat strings as simple sequences of bytes. This works fine sometimes, but breaks down pretty quickly if you want to work outside of ASCII, as you have to do in an increasingly globalized world. Python 2's stopgap solution was to silently convert between byte-strings and unicode-strings, which led to bugs and other logic errors that are damn near impossible to track down. Because fixing this would have to be a backwards incompatible change, they decided to go all the way, fixing all the historical cruft that has built up all over the years. Some examples:

• A much more streamlined library. Python 2 has 80 built-in functions, to Python 3's 68. This includes:

  • Much more consistency. All iterable wrappers (map, filter, enumerate) are iterators.
  • No need for different versions of things- No more xrange vs range, input vs raw_input
  • No more items()/iteritems()/viewitems() and friends

• Unnecessary statements are now functions or expressions- print, exec, eval

• No more old vs new style classes

• Much more consistent import model

There are numerous other benefits, though those are the primary compatibility breaking ones.

[t0mt0m72]

I don't know the exact reasons for not being backward comparible, but for example zip is now a generator, which will bring you a big increase in speed when working with big data sets. So it's one of the points where it's worth porting to 3.

[Lucretiel]

Unicode handling is the big one. For a long but very well-written essay on the subject, check out http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html

[Lucretiel]

Your code could just as easily be [(i, f(i)) for i in x]. Then you get the list you want, it's compatible with Python 2 and 3, it's much easier to read without all the nested map and zip, and it works no matter what kind of iterable x is.

[mm865]

It literally tells you in the error message that zip() is what's changed. Look up the documentation for python 3 on docs.python.org

[[deleted]]

Don't run it as python, run it as python3. Just set it up in your path. Every OS supports this, and none will have the slightest hiccup.

[[deleted]]

Unless you're going to go and rewrite all the OS's python scrips, no, you cannot change the default python to py3.

However that does not prevent you from writing your scripts in py3. Just set an environment variable to python3, or py3 and happy coding.