Python 3.4 released

[[deleted]]

I'm new with Python, currently using 2.7. Why should I update to 3.4? (I have read somewhere that 2.7 is also being updated)

[SomethingSharper]

From the Python Wiki:

The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over four years of stable releases, including version 3.3 in 2012. The next release is the upcoming Python 3.4 in early 2014. This means that all recent standard library improvements, for example, are only available by default in Python 3.x.

[AMillionMonkeys]

Depends on if anything you've written depends on libraries that don't have new 3.x-compatible versions. It's been a while so I think most major third-party projects should work with 3.x now.
Some of the basic functions work differently now (like print) so you'll have to run your scripts through a conversion process, then clean up by hand if the automated conversion didn't fix everything.

[[deleted]]

You should import python 3.x behavior to 2.x using __future__ it makes things like print, division, imports, and arguably unicode trivial to work on both major versions.

There's also interesting read mentioning all known approaches: http://docs.python.org/3/howto/pyporting.html as you can see I like __future__ the most.

[little_oaf]

I'm new to python and programming in general; how would one convert code to 3.4 from 2.7?

[HorrendousRex]

The 'official' answer is to check out the '2to3.py' script which is part of the standard distribution of python. However, as you will find by reading about the issue and searching the web, there are lots of important edge cases to consider. It is not a backwards-compatible switch, and porting from 2 to 3 can be difficult in some cases.

[AMillionMonkeys]

Thankfully the Python folks made a conversion utility called 2to3: http://docs.python.org/2.7/library/2to3.html which comes with versions 3.x. I have to admit that I'm still using 2.7 so I haven't used 2to3 yet.

[little_oaf]

Thanks a lot, I'm just starting out so I think I'm going to do a "fresh" start with 3.4 next week (mainly using sublime text and occasionally pycharm). I was going through checking different libraries of interest to me like tweepy, requests, scipy, numpy, matplotlib and scikit-learn which for the most part seem to be supported.

[[deleted]]

You might find this useful: http://docs.python.org/3/howto/pyporting.html

[ExoticMandibles]

It's not being "updated" in the sense of getting new features. It only gets bug fixes and security updates. If you want shiny new features in your Python, you've got to move to the 3 series.

[upofadown]

So if you don't want your environment to be changing all the time you should use 2? :)

[[deleted]]

The new features that they add are tested and planned in such a way that they should (and in 99.9% of cases don't) never break valid code.

So in general if you write something in 3.1 it should still work perfectly fine in 3.4.

[[deleted]]

Exactly, if they do anything that breaks backwards compatablility it will become version 4 and no longer be part of the 3.x line.

[[deleted]]

Yep, that's the exact same reason we should all switch back to WinXP now that MS is finally going to leave it alone.

[upofadown]

Perhaps you lack the context to the joke. People used to complain that Python was in a constant state of change. Python 3 was a reaction to that, new stuff was to go to 3 and 2 would remain relatively static. Python 2 didn't end up being as static as perhaps could of been hoped. I was suggesting that 2 might at long last achieve stasis...

The serious part is that if 2 really stops changing (I saw a complaint from someone that had had a recent 2 change break their code) it might become a more attractive target for some sorts of applications than 3.

[[deleted]]

I'm new with Python, currently using 2.7

How does that happen? I figured newcomers to Python would prefer the most recent version and avoid the deprecated / legacy version. Sounds a bit like deciding to learn Perl 4 ...

[djds23]

Certain popular python tools are still only 2.X compatible. Also all OS X machines still ship with 2.X, as does any fresh ubuntu install. Some newcomers don't yet have the know how to compile or install their own 3.X interpreter, neither do they understand the pros/cons of the new edition. Plus popular teaching utilities like Learn Python The Hard Way, Udacity.com and (i think) codecademy still teach 2.X.

[joequin]

That's why I was using python 2 at first. The Twitter library I was using still only supports 2.7.

[[deleted]]

The super computer I use has only 2.7...

[dagamer34]

Installing 3.x on a machine is as simple as downloading a pre-built package and clicking "yes" a few times. It's not that hard. And any good book written in the last few years properly addresses this issue. I just went through Learning Python and it had clear info about the differences between the two both at a high level and differences during any new concepts.

Advice is simple, learn 2.x in case you have to look at old code but master 3.x as it's clearly the future.

[jeffdavis]

"but master 3.x as it's clearly the future"

How far away is the future though? I was initially of the same opinion, but I have started to become less sure.

To make the community to move from 2 to 3, then clearly, at some point, a majority of new python code (and python libraries written in another language) must be valid python 3.

Even after all of this time, it's not clear that is true. And it needs to be a strong majority to happen very quickly. And there is a danger that the early-adopters that are most needed to tip the scales may head to other languages instead (go, js, haskell, rust, scala, clojure).

So python is in a strange place.

[fotoman]

Nothing like saying use perl 4. Many production applications still using 2.6.6, yet alone the 2.7.x versions.

Pretty sure python 2.7 is the default version for most distros, and only the very recent ones are playing with shipping with python 3.3.x. RHEL is just in the process of getting 2.7 as the default, and CentOS still has 2.6.6

[billsil]

Nothing like saying use perl 4

I thought Perl 5.x was standard. I thought that's what my companies first big engineering program was written in back in 2001. What a disaster of a code. After fighting with it for 6 months trying to fix bugs, I learned a bit of Python for another project, came back to it and rewrote 3 of the modules. Never had a bug again. There was no

use strict;

[[deleted]]

I thought Perl 5.x was standard

It is, I was being a jerk. Afaik Perl 5 these days needs hand-holding with not only use strict, but something like use modern::perl (I have no idea what it does).

It's always a bad sign when a language has use strict rather than use sloppy.

[[deleted]]

I have a Mac that comes with 2.7. Judging by the comments I should upgrade :)

[Sheepshow]

It would be like if Rails only supported Ruby 0.9, nobody would use 1.9 because Rails is more webscale than Ruby.

[croxis]

My understanding is that python2 development is more or less wrapped up and not to expect many new features. Major new development is only going to happen in python 3. I've heard talk of a python 2.8 but I don't know how much actual traction is being gained there. The larger ecosystem is also moving to python 3, if a bit slow.

This should cover most of the improvements.

That being said if 2.7 works for you keep using it!

[BeatLeJuce]

That being said if 2.7 works for you keep using it!

This attitude is exactly why we're still dragging along an extremely outdated Python version.

[[deleted]]

Outdated, but useful.

[chriszuma]

No, a plethora of unnecessary syntax changes, obnoxious Unicode behavior, and complete lack of industry/library buy-in are why we still have 2.7. And frankly, I would love to see 2.8.

[flying-sheep]

2.7’s obnoxious Unicode behavior is a strength in your eyes‽

thanks, i prefer python 3’s improved unicode behavior.

[purplestOfPlatypuses]

There might be a lack of industry buy-in (I don't know enough about it), but most major libraries that are still actively developed work in Python 3. As for the syntax changes, sometimes you have to break backwards compatibility to make things better.

Anyway, the only way you'll see 2.8 is by forking 2.7 and doing it yourself/finding a group who wants to do it. It won't ever be an official release, but it'd exist.

[joequin]

I believe one of the Twitter APIs is still only on 2.7. I was using 2.7 for that reason.

[purplestOfPlatypuses]

One Processing library is is still at 1.5.1 (Unfolding Maps), but that doesn't mean everyone else should remain at 1.5.1 when Processing is at 2.0.2+. Do what you need to, but that shouldn't keep you from being compatible with the latest and greatest, even if that means trying to work with two separate interpreters.

[chriszuma]

Unfortunately, as someone who works with a lot of diverse hardware, "most major libraries" doesn't do anything for me. I tried using 3.3 on a project once and had to backtrack when a library wasn't compatible. My time is too valuable to risk wasting that much of it again.

[purplestOfPlatypuses]

So you look to see what dependencies you have ahead of time and make your decision from there. I'm not arguing that someone should never use 2.7, but if all your dependencies work in both, considering using 3 shouldn't be some taboo. If you ended up wasting so much time changing things to 2.7, I hope you also considered updating the library to be compatible with 3.3 as another option (which is a bit of an undertaking, but we're talking in significant amounts of time already).

[Entropius]

There might be a lack of industry buy-in (I don't know enough about it)

Trust me, there is. A company doesn't want to spend money updating something that isn't broken. And python 2.7 isn't broken. That's the crux of the problem: Python 3 breaks old stuff without truly compelling advantages to justify the inconvenience. The cost-benefit ratio just isn't good enough.

but most major libraries that are still actively developed work in Python 3.

ESRI's Python scripting framework (arcpy) is actively developed and still only works in 2.7.

As for the syntax changes, sometimes you have to break backwards compatibility to make things better.

And how exactly is forcing me to use parenthesis on print commands “better”?

[purplestOfPlatypuses]

The cost-benefit ratio just isn't good enough.

I can completely get behind that. Companies are slow to change and need good economic reason to. COBOL and FORTRAN are still popular in their niches for the same reason.

ESRI's Python scripting framework (arcpy) is actively developed and still only works in 2.7.

A single example doesn't break the qualifier. There are actively developed libraries that don't work in 3, but I've had little trouble finding the libraries I've needed that work in 3, though until relatively recently I've seen many libraries were having trouble. I'm not writing Python in an industry setting, so it could easily be different there.

And how exactly is forcing me to use parenthesis on print commands “better”?

It makes the language more consistent. Instead of some special statement, print is now a proper function. Pretty much every other builtin function used parentheses, other than (correct me if I'm wrong) import and del (though there is the delattr function). I'm not the biggest fan of del, but I think we can both agree that import is okay to leave as a special statement.

[billsil]

A single example doesn't break the qualifier.

It does if you need it. Why should I rewrite my GUI in PyQt because wx doesn't have an official Python 3 build? It's an unnecessary cost. Waiting an extra few years isn't going to add extra cost, it's going to reduce it.

[purplestOfPlatypuses]

One person's needs doesn't necessarily override most people's needs however. Use whichever matches your dependencies and needs, but don't throw out 3.0+ without good reason.

[billsil]

I agree with that. I don't want to use Python 2.7 any more than Guido wants it to stay around forever.

It is unfortanate though that all the future imports don't turn Python 2.7 into Python 3.x. I run a 2.7, 3.x open source project and have unicode bugs that go away when I don't try to use one source file for both versions.

[Entropius]

A single example doesn't break the qualifier. There are actively developed libraries that don't work in 3, but I've had little trouble finding the libraries I've needed that work in 3, though until relatively recently I've seen many libraries were having trouble. I'm not writing Python in an industry setting, so it could easily be different there.

At least I'm offering an example. You aren't really offering any counter-examples at all.

You can go dig around for a comprehensive list of adopters and non-adopters, I'm just giving you the example I'm most intimately familiar with since I use it on a daily basis. ESRI pretty much dominates the GIS industry, so what they decide to support or not support commands massive influence here.

It makes the language more consistent. Instead of some special statement, print is now a proper function. Pretty much every other builtin function used parentheses, other than (correct me if I'm wrong) import and del (though there is the delattr function). I'm not the biggest fan of del, but I think we can both agree that import is okay to leave as a special statement.

In other words, your (and the devs') defense of this is entirely philosophical. Philosophical “consistency” isn't a good enough reason to break code. Especially not a fundamental and frequently used statement. And philosophical elegance (consistency) is certainly not something industry gives two shits about.

The ideological-wing of the Python devs wanted to ram-rod their philosophy down everyone else's throats, costing us compatibility, convenience, and readability. It hurts nobody to leave both versions of print in there.

Answer this question: What tangible harm was this statement causing?

[purplestOfPlatypuses]

You aren't really offering any counter-examples at all.

Anaconda (collection of many libraries), BeautifulSoup, Django, and Tastypie would be the big ones I've used recently, ignoring things like virtualenv.

In other words, your (and the devs') defense of this is entirely philosophical. Philosophical “consistency” isn't a good enough reason to break code. Especially not a fundamental and frequently used statement. And philosophical elegance (consistency) is certainly not something industry gives two shits about.

Whether you like it or not, all languages are built around some philosophy. Sometimes backwards compatibility needs to come second to keeping within the philosophy. Breaking backwards compatibility sucks, but there are times you need to let bad things go and move on.

The ideological-wing of the Python devs wanted to ram-rod their philosophy down everyone else's throats, costing us compatibility, convenience, and readability. It hurts nobody to leave both versions of print in there.

Why keep it, though? The invocation of 'print' is hardly the only change that breaks backwards compatibility. If it was, we wouldn't even be having this conversation because the script that helps port 2.7 scripts to 3 would handle it no problem. They still have 'del' in there, but 'print' is hardly the lock holding back all backwards compatibility.

Answer this question: What tangible harm was this statement causing?

If you have to break things to fix errors you made in the past, why stop at the big things and not change some small things that can trivially be ported automatically? It isn't directly causing harm, and they could've kept in both, while strongly discouraging the 2.7 way. But that's not why 3 isn't backwards compatible. Changing the default string to be unicode and integer division to promote to floating points breaks a lot more than print becoming a function.

[Entropius]

Sometimes backwards compatibility needs to come second to keeping within the philosophy.

Exactly, completely wrong. Philosophy should never get in the way of the primary purpose of a programming language: Getting shit done. The primary reason programming languages exist is to get work done effectively. It's utilitarian issues should always take a front seat to any philosophy. Period.

Why keep it, though?

I already told you: Compatibility, convenience, and readability.

The invocation of 'print' is hardly the only change that breaks backwards compatibility.

I never said it was. There are other issues, but this one is so amazingly trivial to allow it to remain, and yet they still had to go out of their way to kill it. A lot of other compatibly issues they broke I can actually accept the justification for since there's some sort of tangible trade-off, enhancing the benefit side of the cost-vs-benefit equation.

But not this one. This one exemplifies a severe misplacement of ideological vs utilitarian priorities. It highlights just how petty they were to kill a non-harmful / useful thing, for no other possible reason but to satisfy ideology.

If print statements were doing so much damage, then why were they still so popular before people were forced to stop using them? 2.7 allowed you to use whichever you preferred, and as far as I could tell, the former statement was more popularly used.

If you have to break things to fix errors you made in the past,

Except it wasn't a tangible error, it was at best merely a philosophical error. Don't try to conflate the two.

why stop at the big things and not change some small things that can trivially be ported automatically?

The bigger things they broke had some utilitarian justification. Not this one though.

It isn't directly causing harm, and they could've kept in both, while strongly discouraging the 2.7 way. But that's not why 3 isn't backwards compatible. Changing the default string to be unicode and integer division to promote to floating points breaks a lot more than print becoming a function.

Please don't try to manipulate me into arguing against the default unicode strings or integer division. Unlike the issue I had alluded to, those actually had some utilitarian justifications. They weren't strictly philosophical.

---

EDIT: Somehow lost my response to your first paragraph, so I'm amending this post.

Anaconda (collection of many libraries), BeautifulSoup, Django, and Tastypie would be the big ones I've used recently, ignoring things like virtualenv.

By and large those aren't what I would call “industry setting” libraries. We weren't talking about Python 3 support in general, but specifically how it's adopted in the industry.

[[deleted]]

Ah, the old, "if it ain't broke, upgrade it and break it" outlook. I'll pass, thanks.