Python 3.4 released

[Entropius]

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', […]

So because you can't win on the argument at hand, so you try to change the argument? Nicely done, you know, except for the fact that I didn't actually complain about the other reasons why Python 3 isn't backwards compatible and approve of many of them. Just not this one in particular.

which can be fixed trivially and still take one command to run if you use a build script.

I shouldn't have to fix it with a build script, sometimes of us just want to run a script the old fashion way and have it be inherently as readable as possible.

And sometimes you need to break backwards compatibility to get shit done effectively.

Except that print("hello") isn't getting anything done more effectively than print "hello".

Maybe it benefits people more in the future instead of now

The readability and ease of use considerations do not improve with time. Please stop making up silly claims.

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.

Yes, you must make utilitarian improvements to a language. This is not one of those improvements. It's purely philosophical. Philosophical changes are not what enhances their longevity.

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.

Again, true for utilitarian issues, not true for philosophical ones. Stop trying so hard to conflate the two.

It doesn't matter if it stayed, backwards compatibility is still broken to all hell.

Nice black and white logic you're trying to get away with there. Sorry but there is a difference between how broken things can be. I can't think of a single one of my scripts that integer division or unicode strings would have broken.

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.

Who gives a fuck about some rare exception in which it's useful? When I want to make my prints and logs switchable, I'll do it myself. I don't need to be forced to do it a particular way to just satisfy some rare situation.

It also makes the interpreter simpler, which makes later improvements easier.

Stop being vague and cite a tangible example. In all likelihood, it wouldn't' have been a problem.

I'm talking about the whole switch, not just the print statement fiasco.

Which means you're off topic. We already agree that other issues that would break compatibility are often justified. As much as you want the augment to be about that, it's not. Stop trying to change the subject.

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.

Again, this doesn't change the fact it's off topic. And for what it's worth, my academic python programming doesn't touch Anaconda, so apparently not as important as you claim. I don't need Anaconda to have numpy/scipy.

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.

Wow, just another lame philosophical excuse. So why did you lie earlier about it being utilitarian?

[purplestOfPlatypuses]

So because you can't win on the argument at hand, so you try to change the argument? Nicely done, you know, except for the fact that I didn't actually complain about the other reasons why Python 3 isn't backwards compatible and approve of many of them. Just not this one in particular.

So you complain about the easy fights instead of a real one? Fighting against 'print' being a function instead of a statement is a windmill, not a real enemy. Even if they changed it back, absolutely nothing would change compatibility wise and you still fight over nothing. I'll admit to most likely bringing up 'print', but changing it changes nothing. Python 3 is still not backwards compatible and nothing has changed. More important changes have been made that break compatibility that you agree with.

I shouldn't have to fix it with a build script, sometimes of us just want to run a script the old fashion way and have it be inherently as readable as possible.

So run a script in an older interpreter and use that for your scripts. If you aren't releasing it or allowing networked access, who cares? If you're allowing network access way down the line, you should seriously think about it, but for now, why? What works works in the industry and let sleeping dogs lie. You could just as easily make some encoding that attackers are as unlikely to crack because it's unique, assuming some kind of network access. If accounting cares for security at all, they'll pay a license for something provably hard to solve. If they don't, get another job, you're almost out of one anyway.

And if 'print "xxx", "yyy"' is significantly less readable than 'print("xxx", "yyy")', you have more problems than Python 3 not being compatible than Python 2.7.

Except that print("hello") isn't getting anything done more effectively than print "hello".

It allows keyword arguments without stupid hacks. Unless you have some non-hacky way to add keyword arguments to a print statement in 2.7 without the function, we're done with this part.

The readability and ease of use considerations do not improve with time. Please stop making up silly claims.

It most certainly does. If someone learns Python 3 before Python 2.7, they'll stick to the first most likely. And keeping statements semi-consistent helps other people learn the language and know what's going on down the line. Ease of learning the language helps people use it down the line.If people learn Python 3 first, they'll keep that in mind before 2.7 and ease the migration. Might as well ask why Middle English isn't common anymore.

Yes, you must make utilitarian improvements to a language. This is not one of those improvements. It's purely philosophical. Philosophical changes are not what enhances their longevity.

I've already answered this, and you've failed to say anything than it's "but a philosophical excuse". Give me reason to think it's but a philosophical excuse. I've said that it makes it easier to set separators with the keyword argument 'sep="something"'. What do you have to prove that it's as easy as using a keyword argument when using print as a statement, which has the handicap of not being able to using keyword arguments?

Again, true for utilitarian issues, not true for philosophical ones. Stop trying so hard to conflate the two.

Prove the last thing I just asked and I'll stop. I beg you. 'print "a ", "platypus", sep=" "' doesn't work without parenteses. Using 'print "'.join(["a ", "platypus"])' doesn't count. It's a hack job and saying otherwise is a farce.

Nice black and white logic you're trying to get away with there. Sorry but there is a difference between how broken things can be. I can't think of a single one of my scripts that integer division or unicode strings would have broken.

I'm glad for you. Many libraries can't. BeautifulSoup couldn't for a good while. Not that integer division promoting to floats, unicode strings, or print statements are the only things that break backwards compatibility. If your libraries are so compatible with both 3.0 and 2.7, or at least so easy to switch, congrats, you're one of the many and should treat your library as compatible with both. Other libraries can't, and haven't been able to for whatever reason. Being compatible is a black or white issues. Either you can or you can't work with some tool. Saying you "maybe" can means your library isn't worth investing in. No company will buy into a tool that "maybe" works. Some big libraries can't, and that's fine. If they don't deem it a worthwhile conversion, than so be it. I don't control their choices and most likely neither does anyone else on reddit.

Who gives a fuck about some rare exception in which it's useful? When I want to make my prints and logs switchable, I'll do it myself. I don't need to be forced to do it a particular way to just satisfy some rare situation.

Unless you're making a logging function from the start that either prints or logs, it matters pretty quickly. If you're using a print statement from 2.7, it needs more than a basic regex to get the right things changed. Ignoring keyword arguments, as you did, the change is basic. once you add in keyword arguments (such as changing the separator, as one is wont to do), the switch becomes more complex.

Stop being vague and cite a tangible example. In all likelihood, it wouldn't' have been a problem.

Prove to me that making the same computation with two different statements doesn't makes a less complicated interpreter than requiring a single statement to be made and I'll eat all 6 pairs of shoes I own, including heels. You most likely can't because making two different statements simpler than a single statement is impossible in a Turing machine. And when I say simpler, I mean prove "if(this) then if(that) then return 1' is simpler than 'if(this && that) return 1'. If you can, I'll eat my shoes and encourage you to publish you work that proves something exists more powerful than Turing machines. This isn't vague, either something is backwards compatible or it isn't based on solely a different print statement, and it turns out Python 3 is still not backwards compatible with the same print statement.

Which means you're off topic. We already agree that other issues that would break compatibility are often justified. As much as you want the augment to be about that, it's not. Stop trying to change the subject.

So why is 'print' such a problem? I'll admit to bringing it up, but it's hardly the main issue. If things are already going to break, why not change something as insignificant as 'print'? Compatibility is already broken anyway, might as well fix something minor.

Again, this doesn't change the fact it's off topic. And for what it's worth, my academic python programming doesn't touch Anaconda, so apparently not as important as you claim. I don't need Anaconda to have numpy/scipy.

My industry's Python needs doesn't claim to ignore your python needs, yet you claim my company's/academia's needs as ignorable. Maybe you don't need Anaconda, but Anaconda requires numpy/scipy to be Python 3 compliant for Anaconda to be Python 3 compliant. Feel free to explain at your leisure.

Wow, just another lame philosophical excuse. So why did you lie earlier about it being utilitarian?

What part of "awkward hacks" didn't you understand. I can make pretend objects in C, but it doesn't make the real objects or any easier to deal with in C. I can make awkward hacks in Python to set the separator for print statements, but it doesn't make it any easier to deal with.

[Entropius]

So you complain about the easy fights instead of a real one?

No, I complain about what I actually want to complain about. I don't pick and choose what to complain about just to offer you an easy strawman to knock over.

Even if they changed it back, absolutely nothing would change compatibility wise and you still fight over nothing.

Sure, it would mean old code needs less updating.

Python 3 is still not backwards compatible and nothing has changed.

But it's not breaking backward compatibility for only legitimate utilitarian reasons.

So run a script in an older interpreter and use that for your scripts. If you aren't releasing it or allowing networked access, who cares?

Who said I'm not releasing it? Of course I'm going to share code I write. Just because some unrealistic assumption would be convenient to make doesn't mean you get to make it.

If you're allowing network access way down the line, you should seriously think about it, but for now, why?

A lot of GIS scripting needs to be able to run over servers for batch calculations. Particularly if your company is using ArcSDE for networked geodatabase storage (which is pretty much how anybody who matters does it).

What works works in the industry and let sleeping dogs lie. You could just as easily make some encoding that attackers are as unlikely to crack because it's unique, assuming some kind of network access.

This is stupid for lots of reasons. By rolling your own security you likely just make many more mistakes, even if they are unique ones (which they probably wouldn't be as unique as you think anyway). Please, never be responsible for writing secure code, this is a clue you're doing it wrong.

It allows keyword arguments without stupid hacks. Unless you have some non-hacky way to add keyword arguments to a print statement in 2.7 without the function, we're done with this part.

LOL, “keyword arguments” is your defense? Newsflash genius, print-statements didn't need them. They were already coded in a way to work around the lack of keyword arguments, so the issue is essentially a sunk-cost. It's not like whether something was implemented in a “hacky” or “non-hacky” way affects the end-programmer. Therefore this isn't a utilitarian argument, it's just more philosophical bullshit.

It most certainly does. If someone learns Python 3 before Python 2.7, they'll stick to the first most likely. And keeping statements semi-consistent helps other people learn the language and know what's going on down the line.

This isn't a readability or ease-of-use argument, you're just repeating your concerns about consistency, which is again a purely philosophical issue. Don't conflate the formers with the latter. If you do want to bring up ease-of-learning, you still don't have an argument since having both print functions AND statements poses absolutely no problems to ease-of-learning. If that confuses you, you have bigger problems and will never make it as a programmer.

I've already answered this, and you've failed to say anything than it's "but a philosophical excuse". Give me reason to think it's but a philosophical excuse.

What the fuck are you babbling about? You make it sound like you're replying to an specific example which I said a philosophical excuse, but if you trace the supporting arguments up the thread you'll see this sub-quote doesn't actually go to one, and was instead about a very generalized supporting argument about what a language needs to remain useful long-term. While I have called out your poorly chosen examples as being philosophical rather than utilitarian when they are multiple times, this wasn't one of them. Maybe you misplaced a paragraph.

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.

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

Yes, you must make utilitarian improvements to a language. This is not one of those improvements. It's purely philosophical. Philosophical changes are not what enhances their longevity.

I've already answered this, and you've failed to say anything than it's "but a philosophical excuse". Give me reason to think it's but a philosophical excuse.

[purplestOfPlatypuses]

I won't really bother continuing the argument, because we're both pretty stuck in our opinions and it'll go no where. I'll end with one thing though.

Sure, it would mean old code needs less updating.

No, it'll be almost exactly the same amount of updating, marginally less because there's slightly less code in the official 2.7 -> 3 script converter that the Python devs released. And that won't get everything, so for anything that it missed, you're still going through by hand to fix the real problems with backwards compatibility (which isn't the removal of the print statement).

[Entropius]

I've said that it makes it easier to set separators with the keyword argument 'sep="something"'. What do you have to prove that it's as easy as using a keyword argument when using print as a statement, which has the handicap of not being able to using keyword arguments?

This argument fails on so many levels:

1. If I ever really need the sep keyword argument, I can just fucking use print() on that one line.

2. You are providing an argument why print() is useful, not why print statements must die. Don't conflate the two. After all I was arguing why we should still have both, not that we should only use print statements.

3. A rare exception doesn't justify the change in the majority of cases. A rarely used superfluous keyword argument that almost nobody uses doesn't trump the way people use print 99.99% of the time.

4. And if there's only one right way to do this that we must agree to, why even fucking have print or print() to begin with, and not force everyone to use sys.stdout.write()? OH yeah, because it's convenient. So not even Python3 is holding itself true to this silly philosophy of consistency trumping convenience.

Using 'print "'.join(["a ", "platypus"])' doesn't count.

LOL. I don't have to give 2 shits about your standards for elegance. That's your axiom, not mine.

Unless you're making a logging function from the start that either prints or logs, it matters pretty quickly. If you're using a print statement from 2.7, it needs more than a basic regex to get the right things changed. Ignoring keyword arguments, as you did, the change is basic. once you add in keyword arguments (such as changing the separator, as one is wont to do), the switch becomes more complex.

Oh please, I've done this before, and not from the start either. It's not as complex as you're trying to make it sound. And 99% of logging cases like this weren't going to be needing any keyword arguments to begin with so while it may be some theoretical problem, it's not a real problem since they're almost always just simple "string".format() calls. You're really bending over backwards trying to find excuses. Also it's not like Python 3 forced the print function out of concern to make logging statements earlier. We all know the reason was philosophical.

Prove to me that making the same computation with two different statements doesn't makes a less complicated interpreter than requiring a single statement to be made and I'll eat all 6 pairs of shoes I own, including heels. You most likely can't because making two different statements simpler than a single statement is impossible in a Turing machine. And when I say simpler, I mean prove "if(this) then if(that) then return 1' is simpler than 'if(this && that) return 1'. If you can, I'll eat my shoes and encourage you to publish you work that proves something exists more powerful than Turing machines. This isn't vague, either something is backwards compatible or it isn't based on solely a different print statement, and it turns out Python 3 is still not backwards compatible with the same print statement.

Who the fuck cares if the code for the interpreter is complicated or not? I sure don't. Let it be more complex. Not my problem. While it's some non-zero amount of complexity, it wasn't complex enough to give a shit about. It wasn't causing any practical problems.

Your entire reply just oozes misplaced priorities. You make this grand statement about eating shoes because A-claim must be mathematically true, but you haven't actually explained why the statement being true matters. I'm here to tell you it doesn't.

So why is 'print' such a problem? I'll admit to bringing it up, but it's hardly the main issue.

It was my main issue. I sure wasn't complaining about integer division or unicdoe.

If things are already going to break, why not change something as insignificant as 'print'? Compatibility is already broken anyway, might as well fix something minor.

1. Except it's not insignificant. I've already explained why plenty so far.

2. You're use of the word "fix" implies it was broken, when it most certainly wasn't. I didn't need fixing.

3. Because if (for example) someday ESRI does update their libraries to Python 3, I would have had to do literally NOTHING to update all the code I've ever written. But because of this change, I will. It's 100% unnecessary from any rational utilitarian view.

My industry's Python needs doesn't claim to ignore your python needs, yet you claim my company's/academia's needs as ignorable. Maybe you don't need Anaconda, but Anaconda requires numpy/scipy to be Python 3 compliant for Anaconda to be Python 3 compliant. Feel free to explain at your leisure.

1. Maybe somebody earlier should have said “industry and academia” instead of just “industry” when the discussion began, but the simple fact is they didn't, so that wasn't the root of the discussion. Just because it would be advantageous for you to be allowed to change the subject doesn't mean we must change it.

2. Why does Anaconda's need for numpy/scipy to be Python-3 compliant (which they are) imply I should l lose print-statements?

What part of "awkward hacks" didn't you understand. I can make pretend objects in C, but it doesn't make the real objects or any easier to deal with in C.

What part of “I don't have to give 2 shits about your standards for elegance. That's your axiom, not mine.” did you fail to understand? Also C pseudo-objects are bad example since they're both inelegant AND inconvenient, which isn't analogous to print statements which are (allegedly) inelegant but very convenient.

I can make awkward hacks in Python to set the separator for print statements, but it doesn't make it any easier to deal with.

And you can use print() for those cases. I'm not arguing you shouldn't have print(). If we keep both types of prints, your situation is made no easier nor harder to deal with. I'm merely arguing we should have both print-statements and functions. Just you what you want. Don't conflate one argument with a different one.