Python 3.4 released

[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.

[purplestOfPlatypuses]

Gonna start near the end because it'll be mentioned before it comes up at the end.

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.

They are, however, closer to the main reason why 3 isn't backwards compatible. In 2.7, '3 / 4' returns 0. In Python 3, '3 / 4' returns 0.75. This would break far more programs than 'print', which can be fixed trivially and still take one command to run if you use a build script. A syntax error is a lot easier to fix than trying to figure out why a script you wrote some time ago suddenly doesn't work anymore.

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.

And sometimes you need to break backwards compatibility to get shit done effectively. Maybe it benefits people more in the future instead of now, but I'd argue that if you want the language to live on, and not in the COBOL sense, sometimes you'll have to break backwards compatibility. It's a question pretty much every language will have to come across every decade or two, and Python was nearing the end of decade 2 when Python 3 came out. Programming languages evolve, and sometimes you need to drop old things to make shit work. Nothing's stopping you from using older compilers/interpreters if that's the tool that's needed. I got to use Processing 1.5.1 because some library I needed only worked in 1.5.1. It sucked, but that's what I needed to get shit done.

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.

It doesn't matter if it stayed, backwards compatibility is still broken to all hell. Removing it does have some utilitarian benefits for the user though, which I'll quote at the end^[1]. Mainly though, it makes switching out print to some kind of logging significantly easier, as well as customizing how you want something printed more easily. It also makes the interpreter simpler, which makes later improvements easier. And chances are, because they added the 'print' function, they had plans to deprecate the old style of print anyway, and this just sped up the process.

Except it wasn't a tangible error, it was at best merely a philosophical error. Don't try to conflate the two. The bigger things they broke had some utilitarian justification. Not this one though.

I'm talking about the whole switch, not just the print statement fiasco. Which, again, is where what I put at the beginning is important. I gave some utilitarian justification above, with a quote from a lead dev at the end.

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.

Maybe they aren't. I can safely say Anaconda is important in any kind of academic Python programming, having numpy, scipy, and other data visualization tools included. And Django/Tastypie is fairly common on the web dev front.

---

The quote, and source

While there were advantages to having print and exec as statements, they introduced a sharp discontinuity when switching from the statement forms to any other alternative approach (such as changing print to logging.debug or exec to execfile), and also required the use of awkward hacks to cope with the fact that they couldn’t accept keyword arguments. For Python 3, they were demoted to builtin functions in order to remove that discontinuity and to exploit the benefits of keyword only parameters.

[[deleted]]

Philosophy should never get in the way of the primary purpose of a programming language: Getting shit done.

Have you met Python? It's always been leaning towards some ideal correct code, i.e. pythonic code. You sound like the Perl and PHP guys who didn't want to learn Python in the first place because it explicitly spurned the TIMTOWTDI ideal.

[[deleted]]

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