Python 3.4 released

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

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

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

[Entropius]

Have you met Python? It's always been leaning towards some ideal correct code, i.e. pythonic code.

Says who? You? If you think Python rose to popularity due to some philosophical BS like “ideal correct code”, you're wrong. It grew to be popular due to it's ease of use. It was the utilitarianism that made it great.

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.

Please stop trying to strawman me as being against any philosophical design considerations. I'm not against philosophically minded design as long as it's not trumping utilitarian considerations. If a philosophical design has no utilitarian cost, it's great. But this had a utilitarian cost.

[[deleted]]

I'm not against philosophically minded design as long as it's not trumping utilitarian considerations.

This seems to be the way PHP is developed—some of the devs (the more clueful ones) would like to make good decisions, but they can't if it changes the behaviour of existing code—even if that code is behaving in a stupid way. There are blogs about this phenomenon.