What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you.

> Unlike 2.7 code, Python 2.8 wouldn't be able to guarantee exact 3.x compatibility, since there are some python scripts that will run under both Python 2.7 and Python 3.x but produce different output, and Python 2.8 chooses the 2.7 behavior in these cases.

What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x. As for the latter, please explain how that will alleviate anything on the following point, since behaviour at runtime will be subtly different:

> adding these remaining Python 3 features would greatly simplify running code targeting Python 3, and allow people to use Python 2.8 to run a mix of Python 2 and 3 code.

I don't know what recourse the PSF has but maybe they should even go all in and defend the "Python" name so as to prevent confusion and stop a potential community fracture. Just call it anything else but "Python 2.8" is not Python.

This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But please, don't use the Python name! It will create more confusion than help. This fork with a different name is 100% fair in my opinion.

While I wish Naftali well in his efforts - I have a private Python-derived language myself! - this is not "Python 2.8." For trademark purposes, "Python" is only what is released or endorsed by the PSF.

We have already reached out to Naftali and asked him to change the name of his project and update this blog post accordingly.

Obviously, though, this is someone who cares a lot about Python, so let's be sure not to rain down on him with a lot of scorn; I admire that he was willing to sit down and 'scratch his own itch.'

Source: I am the General Counsel of the PSF.

  - The Author (who isn't me)
    https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266240525

I call BS (to counter your "bollocks").

Whether the "writing was on the wall" or not, doesn't change the fact that people had to actively port their old code if they wanted it to run on 3.

Sometimes that code could run into the tens of thousands (or even millions for large companies) of lines.

And why would they do it (and at a great cost and time effort)? For the marginal improvements Python 3 brings?

The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that.

However, at a certain point it is worth your time to move forward instead of doing nothing, you gain a little time savings now and you run into few moments of "Oh @#$%^!!" later. Real world example: You don't bother updating ssl to deal with weak DHE and suddenly chrome users can't see your payment site.

My approach has always been to try to front load the work instead of doing it in crisis mode later. It sorta sucks but that's just how software is right now.

If IE7 was slower than IE6, you can't blame people to not move over.

As for Python 2... well, there are still people signing petitions for Microsoft to bring back VB6. Last one was this year, I think.

There are however non backwards compatible changes, like unicode by default, IE7 was also non backwards compatible so the comparision still holds. (with the exception that IE had a compatibility mode if you sent some magic http headers)

It seems fine now, but there is nothing, as far as server side application coding is concerned, that would make me want to switch from Ruby/Rails.

Would you also call the RHEL life cycle a blackmail? I'm using version 5 now and the normal support ends in March 2017. My options now are "port or pay extra for extended life cycle or else my RHEL will be without security fixes". And like Python, major RHEL versions break backwards compatibility.

Honestly, that 10 years later we're still having this conversation is ridiculous.

The RHEL life cycle is based on real business needs (and a real business need to balance between newer releases/features and stable environments).

Not on some decree from above that "you should use this new thing".

If you e.g. can't be bothered to do continuous integration or automated testing, then you might consider RHEL with it's life cycle to be an acceptable alternative. Which is fine. Just be ready to pay for that service.

Similarly, if you wanted continued Python 2 support, you could have donated time or money towards that goal. I would be surprised if anybody complaining did that. There's just not that much business value in dragging legacy Python further along.

But to keep it running, you don't really need Python 2.8 with new features, right? You need extended support for Python 2.7 - basically, making sure that it keeps working with updated versions of other software (like OSes), and that bugs are fixed.

Those systems are not just sitting there untouched.

Heck, not even 70s COBOL systems are "just sitting there" (they are hooked to newer systems, get new forms, have alterations, etc. all the time), and those Python 2.7 systems have been written 10-15 years before or less.

And they continue to get new subsystems, new features, alterations, etc. In 2.7.

So, yes, people would very much like to get not just "extended support for 2.7" but also the ability to keep running it in newer versions, and be able to take piecemeal adoption of new features to make their life better and eventually organically refactor in their own timeline.

So let me get this straight.

1. A bunch of people you've never met and probably have never paid or financially supported,

2. Gave you a high-quality programming language, for free, to use for any purpose you liked,

3. And then when you and they disagreed about the best way forward in a new version, you claimed their refusal to continue supporting and adding new features to the old version for you, for free, essentially forever, constitutes "blackmail" on their part.

Do I have that right?

1) You frame this as some single random individual on HN is the only one that is concerned with the switch.

2) You seem to have missed that companies and individuals that do dislike the switch have contributed to the Python ecosystem, from employing core developers in the past, to creating frameworks, libraries etc that helped Python succeed.

3) You have missed the fact that some (a lot? most?) of the concerned people have actually donated to the PSF through its PayPal donate link (as I've done in the past, and I've used Python since 1998).

4) You seem to think that an open source community project is pretty much "anything goes" and end users be damned. And then the team can complain about "lack of adoption" for the new version.

Do I have those right?

Python 3 adoption has been rising for a couple years now as people realize that A) Python 3 is a quite nice language, B) porting to Python 3 is not as hard as people keep claiming it is, and C) Python 2 is going to run out of zero-dollar-cost support one day as the number of people willing to support it without being paid for their trouble diminishes.

If someone does want to commit to supporting Python 2 + backported Python 3 features, they are of course welcome to do so provided they observe the license and trademark terms (not terribly hard to do). But I suspect it won't last very long, at least not as a small-team zero-dollar-cost project. Between Python 3 gaining steam and people staying on 2 in order to avoid work and expense, I just don't think it's going to work out on the kind of decades-long horizon the Python 2 die-hards seem to want.

Here we have a person (the author) who has rejected the path that an open source project has taken, and invested the time and energy to move the source along a path they prefer.

In this particular case, there is a natural constituency of people who share that desire but are unable or unwilling to put in the effort to push the source down the path.

When there is critical mass, that group forks off and begins to bring other people along to the alternate path.

At that point the people who endorsed the change in direction come out in force to yell at these people who aren't doing what they are supposed to and threaten them and implore a higher power to emasculate their effort.

Sometimes that works, sometimes it doesn't. But it always results in massive amounts of confusion when someone new comes to the community and sees these two different paths for the same thing and can't really figure out why they are different.

Further because there is no mechanism for "righting" the ship as it were, the diverging paths lead to a lot of wasted time and effort on everyone's part. This happens to be a Python fork but its happened to window systems, video codecs, graphics libraries, data bases, hell even C compilers.

The nice thing about a Cathedral is that the Pope keeps the Cardinals toeing the one and only line.

Reminds me a lot of the Perl 5 / Perl 6 debates.

They own the Python trademark, so they can make him stop using it.

In fact, I really hope that they do. This project does no good.

I don't expect litigation because that's not how the community rolls. I expect a polite message from gvr to the author asking to change the name.

If that fails, the PSF has no choice. It's use it or lose it.

And he has - https://github.com/naftaliharris/python2.8/issues/47#issueco...

Or license it.

When Python 3 was released, it offered Python users a trade: In exchange for a productivity loss (porting your Python 2 code), you'd get a productivity gain (new features in Python 3 and removed cruft). Some projects and companies thought this was a good trade, and have upgraded over the years, and many have not, and haven't. The interpreter I've been working on tries to improve on the terms of that deal for people who have not switched to Python 3.

> What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x.

That's the point, yes. Obviously any interpreter that's backwards compatible with 2.7 but includes new features from 3.x is going to let people write code that doesn't run under 2.7 or 3.x. But what does it matter if your code doesn't run under interpreters that you aren't using and don't intend to use?

> Just call it anything else

I'll change the name.

Except when they aren't. And then what?

I've run into this multiple times. Sometimes there's a branch of the project for 3 that's underway, and I sit and wait. Other times it means dropping the project or committing to reimplementing a library.

Python 3 is not only the future but the current version of Python. It is the version kids learn in School (in the UK kids do some CS from the age of 6 or 7, starting on scratch and then normally Python), it is the version colleges teach.

However there are lots of reasons enterprise users may want to use a legacy codebase. It is not like Python 2.7 is about to stop working! When a section needs a major re-write, then consider porting it. I don't see how this is different to any obsolescence problem. I know an enterprise software company that wrote a lot of stuff in VB6. Some of it is still in VB6 and they have to manage everything that means (especially around 64 bit architecture problems), when they do major updates they use .net. How can we be in the technology game and not just except that life moves on!

I found it's easy enough to add the line:

# -- coding: utf-8 --

to the top of my Python 2 files so I can get UTF-8. That, and Python 2 has the bindings for GTK (which I like to use). Both versions of the language have their usage, and to each his own. There's no sense in bickering about it.

Text handling is the same. The thing is, many people just deal with ascii compatible English so they don't realize this is a problem for other people and aren't motivated to change. The reason both sides can't just do their own thing (i.e. Python2) is because of libraries and shared code makes it miserable for people using other character sets (most of the world or any company growing bigger than a certain size).

For the record, that's not what anyone's talking about when they mention Python 3's unicode support.

But the runtime is still supported - in fact, it ships with the OS! If you have any non-ARM version of Windows, up to and including Win10, around, check the file named msvbvm60.dll in C:\Windows\SysWOW64 - that's it ("MS VB VM").

And because it ships as an OS component, the official support policy is the same as the rest of the OS, which is at least 5 years of mainstream support (longer if there's no successor release), and then at least 5 years of extended support. This is even clarified specifically for VB6:

https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

Since VB6 was first released in 1998, this marks 18 years of continued support to date; and if it's not dropped from the OS within the next 2 years, it has a chance of hitting 30 years...

For what it's worth, PSF also has a fairly generous (especially for a non-commercial OSS project) support policy for Python 2.7 - it had already extended the end-of-life date for it once to 2020:

https://www.python.org/dev/peps/pep-0373/#id2

They are only trying to run out the clock on other people's interest- an effort to kill Python2 so it doesn't evolve.

I don't say you are wrong, but I am afraid this situation looks "terrible" only to people who do care about 3. If someone doesn't care about it and thinks that he can survive with never porting to 3 or start using it, for those people the situation isn't that terrible...from that perspective, his 2.7 language evolved to next step, and he know that new features can be used if he upgrades from 2.7 to 2.8.

The majority of Python code is old projects, just like every other established language. This might change in the future as I now see people starting new projects in Python 3, but if your company is older than 5 years old, then there is a good chance that you started with Python 2 simply because at the time of creating your codebase a whole lot of libraries weren't ported to Python 3.

We would look very closely at a Python 2.8, if it existed.

Also, I don't know what you mean by "Amazon only supports 2.7" because boto (the main client for Python) has supported Python 3 for 2 years now. Perhaps you mean Lambda?

Genuinely curious as i thought nearly all of the main ones were ported now

Curious. What do you mean by that?

"Starting fresh" is something many (most?) companies simply never does, over decades. (And if they attempt it is often an all out disaster..)

2011 is fairly recent in this context, and many popular libraries were not available on Py3 until much more recent than that, even if you have the rare luxury of starting fresh.

Only recently 3.x has become a viable alternative. I for one welcome this 2.8 fork.

I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.

It is possible actually, that's kind of the point! The interpreter I've been working on passes the 2.7 unit tests (i.e. those in Lib/test/), and as well as unit tests for the new features that have been backported from Python 3.

Even if you don't believe me, it's interesting to note that, e.g., while Python 3.0 was being developed, function annotations and keyword-only arguments coexisted with tuple unpacking. I built the code and ran it myself, in fact: https://twitter.com/naftaliharris/status/784421498291310592. Tuple unpacking was actually removed later, introducing the backwards incompatibility after the new functionality had been added. Timeline:

Oct 2006, keyword-only arguments.

Dec 2006, function annotations.

Mar 2007, removing tuple unpacking.

There was also a promising backport of keyword only arguments to CPython 2.6 (!) that was never merged, (http://bugs.python.org/issue1745), due to lack of follow-through.

Why isn't it a valid Python compiler?

To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation.

On one side, people like Zed Shaw are calling the Python maintainers 'evil' and claiming conspiracy.

On the other side, people are calling companies using Python 2, 'lazy' and claim they're a threat to the ecosystem.

Yet elsewhere, C is still being written in all of its various year-specific formats, and people end up using 'old' versions simply because they join pre-existing projects or need to totally interface with something that's written in an 'old' version.

Python is an extablished language, it's likely that 10 years from now there will still be Python 2 codebases going strong.

My biggest gripe with this project besides calling this Python is that it's seemingly ambiguous with its code compatibility. I don't mind ambiguity in programming languages, but generally the ambiguous cases are explicitly defined with cases to explain them, and I don't see anything of that nature here, only something that vaguely says that if there's something that works in both the Python 2.7 way will be the default. Without defining those it's hard to know what could happen in an edge case and this could introduce specific bugs that don't present themselves immediately but introduce data weirdness because the cases where something may be ambiguous wasn't defined.

In any case, I think that if a company has a really big, maintained code base in Python 2, it's their fault for supporting an older, in-2020-unsupported version of a programming language and the money/developer time spent supporting the codebase could be spent transitioning it to Python 3. I can understand a little more with an open source project because time is more precious and generally that time is donated, but even then most bigger projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so unless the project is gargantuan there's no real excuse besides the project is not maintained.

Except it isn't.

So scoff all you want, but Python 2.x isn't going away that soon.

In the Java world (conservative and slow-moving) JRE 7 (2011) is considered the absolute minimum, and if you're not targeting JRE 8 (2014) you have to have a very good reason.

You mean like, dealing with strings and Unicode? That's usually the case why people have trouble migrating to Python 3.

- There is a community that wants it (largely enterprise).

- The Python team does not want it.

A less controversial word is deprecated - the Python team is discouraging use of Python 2, but not prohibiting it's use or development. That's fair, and if you read this page:

https://wiki.python.org/moin/Python2orPython3

they are not very opinionated about it, largely saying "Use 3, unless you can't, then use 2 and start trying to migrate, unless you can't, then just use 2."

I will say, not to give somebody a bad day but, 2.8 seems like a bad idea. Currently python's development has still largely been a straight line, which is good for transitioning, but 2.8 would cause a fork. It would give a lot of people a short-term win for a long-term lose. Better not to tempt people.

Like you said, Python team sees the 3.x series as the successor AND as a replacement for Python 2.x. They were never meant to exist one beside the other (or, there was no thought put into this before the release).

From my perspective, giving people the choice between 2 or 3 will only give us problems down the road, which is why I vehemently discourage it.

I wonder what about this made this difficult. Was it because it's a language interpreter? Libraries have this problem sometimes, but not as much. (I never hear of issues with gstreamer between 0.10 and 1.0, for example.) Maybe it was just that a binary called python existed? Maybe we should have just said "screw it, python means python2, end of story."

Don't know. What would you have preferred?

In my field what seemed to keep people on python 2 for a long time was numpy or scipy (or both, I do not remember which) which did not get a 3 upgrade for a long time.

Either that, or just call it something different, kind of like perl6. There is no perl6 distribution shipping a perl library or some perl.dll that clashes with perl5.

Regarding adoption, it's 3.0 that's obsolete, and 2.7 that's vibrant. Even for new code (they conveniently only count totally greenfield projects, but most new code is written in fact to work with established 2.x codebases under Python 2, not as a totally greenfield project).

What numbers? All the numbers I've seen -- official numbers from PyPY etc) tell otherwise.

Also, your anecdotal data is arguably biased as well.

My take is that many sources, including the ones linked to in the tweet's replies point to solid growth in Python 3 adoption. Python3 might not have overtaken Python 2 overall, but it's very far from being "dead".

No, I asked for a representative data source (representative was implied: a biased data source is as good as no data source at all).

I wasn't making the point that Python 2 is dead, in fact quite the opposite. I'm saying that with this many users the adoption rate is too slow. There is no real reason for people to switch. Until there is that incentive Python 2 will not die.

https://semaphoreci.com/blog/2016/11/11/python-versions-used...

http://astrofrog.github.io/blog/2015/05/09/2015-survey-resul...

Downvoting because Python 2 is anything but obsolete. People still love using it.

The fact that people love and use something doesn't mean it cannot be obsolete.

At work, I care about more than 35 years old software. It is obsolete (it's written in mainframe SAS with 3270 green screens and some assembly), but people still love using it, mainly because there is no good alternative and it does the job very well.

For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as:

1. no longer produced or used; out of date.

Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer used" nor "out of date"...

I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards.

Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. So "out of date" is the fitting equivalent of "obsolete" from the Oxford definition.

That's just what the lead project team declared. Not what the user base asked for or wants.

>You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards.

That's because people stopped using them organically. That's not the case with Python 2 -- Python 3 was declared "the new hotness" with a decree from above.

It's like as if the W3C comes out with some incompatible HTML NG on their own and says that HMTL 5 is "end of line", giving billions of webpages the middle finger.

Even worse, it's also as if HTML NG only had some marginal improvements over HTML 5, and was otherwise the same.

You think they are doing it just for kicks? There are no issues with Python 2? They are also part of the user base, and they did it for a reason.

> That's because people stopped using them organically. That's not the case with Python 2 -- Python 3 was declared "the new hotness" with a decree from above.

Well, I for instance stopped using Python 2 when Python 3 came out, if it was possible for me to do so (I had all the libraries I needed). I understand that many people can't do it, but people are organically moving from Python 2 to Python 3, not the other way around.

Nobody is really forcing you to not use Python 2, just as nobody is forcing you not to use FORTRAN 77 or COBOL 74. It's just that the language will not evolve anymore, and as far as runtime goes, you will be on your own eventually.

> It's like as if the W3C comes out with some incompatible HTML NG on their own and says that HMTL 5 is "end of line", giving billions of webpages the middle finger.

I think I already addressed this in my other comments.

Yes. From a false sense of "we know better than you what's good for you". And also from not being connected to actual business and end user needs.

>There are no issues with Python 2?

That's irrelevant. There are issues with Python 3. Besides, the issues that Python 3 fixed over 2 are marginal at best and most could be retroffited to 2.x (as this 2.8 release proves). Nothing earth shattering to make the transition worth it.

>Nobody is really forcing you to not use Python 2, just as nobody is forcing you not to use FORTRAN 77 or COBOL 74. It's just that the language will not evolve anymore, and as far as runtime goes, you will be on your own eventually.

It's more likely that Python will suffer from people moving to other languages (and already, first Rails and then JS have won the server side over Python big time, and JS looks poised to be more general use too), than that anything good will comes out of this "you're free to use 2.x, it just wont be updated anymore".

I am not really personally bothered by Python 3 being incompatible (with that one Jython exception that I already mentioned). But I would like to point out the comment https://news.ycombinator.com/item?id=13146127, I think you're the one who is wrong here.

> It's more likely that Python will suffer from people moving to other languages

Unlikely. Rails are probably going out of fashion. Javascript is a terrible language, which only saving grace is a decent support in browsers. I am not sure for what other reason, choosing a language today, I would choose Javascript over Python 3.

So people moving from Python 2 are most likely to end up with Python 3, I don't really see compelling alternative for them (unless they are going to something more functional like Clojure or Haskell or Scala, but that's entirely different discussion; for example I like Python a lot but I feel pure functional is where the future is, I find the imperative programming quite annoying these days, I would prefer Haskell, but frankly, I am not nearly as productive in it as I am in Python, because Python's focus on usability is very hard to match by any language).

On the other hand, I think Python 3 will actually gain in science and data analysis thanks to things like @ operator for matrix multiplication.

I see no future for Python be that 2 or 3. It's not great at anything, but projects a veneer of friendliness (that one should quickly outgrow) on top of a pile of bad implementation decisions and terrible design.

Its popularity is based on superficial attributes rather than solid foundations. Eventually, the entire ecosystem will collapse and the masses will flood to the next attractor.

Go is interesting, but really a different (and perhaps smaller) use case. What, for instance, I do in Python? That little one-off script that converts one thing to another or calculates something - I am not sure why I would even bother thinking about Go.

I have no doubt that at some point, Python will be replaced by something. But I don't think it will be any of the languages that are currently in widespread use. Heck, C is also not based on solid foundations (I mean like type theory or something), and it wasn't fully replaced yet.

C is based on the solidest possible foundation: the actual hardware CPU.

The situation with C89 and Fortran 77 is completely different than what you see today with Python 2 vs Python 3. For 99.9999% of C89 and Fortran 77 code you can build the old code with new C and Fortran compilers and use it from today's standards. You can take a piece of code written 30 years ago, recompile it and it usually works.

I am pretty sure there is theoretical way to run Python 2 code alongside Python 3 code, but they simply decided it's not worth the effort.

Edit: I think historically Python 2/3 divide is more akin to Maclisp/Common Lisp divide, but in the latter, the situation was even more complicated. But I doubt you can just take Maclisp code and run it on Common Lisp implementation, despite that fact that it was meant as a successor.

The word you are looking for is "deprecated", not obsolete.

Really? So even if no one ever uses it, it still renders the old one obsolete?!

This is a strawman, because I don't think this ever happens (feel free to give an example). There will always be people who try to use new standard; they may abandon it later, but they will at least try to use it.

In any case, this is not really relevant to Python 3, which is used plenty and more and more every day.

And your insistence that Python 2.7 is not dead really reminds me of this sketch: https://www.youtube.com/watch?v=npjOSLCR2hE

> This is a strawman, because I don't think this ever happens (feel free to give an example). There will always be people who try to use new standard; they may abandon it later, but they will at least try to use it.

...I thought it was obvious I didn't mean the case where literally NO ONE was using it, but apparently it wasn't. Sorry. My point was, if it doesn't catch on, then does it still render what came before it obsolete? Is it only about time and whether it fixes some things from before? Not about whether it's actually used, or whether it introduces other problems, or whether the previous technology is still in widespread use, or a million other factors? Really?

As for Python 3 being used and more every day, yes, I never claimed it was obsolete or dead or anything else. I'm just saying Python 2.7 is being used too, and hence it's not obsolete either as you seem to think. You claimed it was, so I asked for your definition of the term. You're rejecting the standard one and you still haven't given me one that you're willing to apply to things other than Python. Not to mention I don't see why software deserves special treatment for the word's definition here.

I already gave you a definition of what it means to be obsolete for standards (such as specifications of programming languages).

In general, an old standard will become obsolete once the new standard (that is supposed to replace it) is finalized (for example, in RFCs, they explicitly say that). At that point, there are probably no serious users of the new standard yet, so the actual usage doesn't matter.

Of course a standard can be de facto rejected by people abandoning it instead of accepting it. Then usually there will either be another standard that obsoletes the old one again (as was a case with XHTML and HTML 5), or people will move on entirely to something else; in either case, the old standard will remain obsolete.

How in the world was my definition "arbitrarily-chosen"? I literally chose definition #1 on Oxford English dictionaries. That's arbitrary?!

    feature proposal -> patch -> review -> merge

For comparison, C is not obsolete because a lot of useful programs are easiest to express in C still. I'd argue that C is obsolete for App development too, but there will be people who disagree with that.

T-shirts are still being made; verdict: not obsolete

Python 2 is not still being made; verdict: obsolete

Similarly, Python 2 might not be made anymore, but it is used everywhere, and people are making new things with it. So...it's also not obsolete.

Python 2 is still being "worn" by millions of programmers, and is what runs in the biggest installations. This includes new code written for those installations, that it's written to run in the same 2.x environment.

That is within the rights of a manufacturer though. Coca Cola can continue to produce classic coke because it isn't any more or less complicated to produce than New Coke. The PSF's opinion is the new features they develop are best developed on top of the core changes in Python3, and that adding new features to Python2 is too expensive to maintain in addition to Python3. I feel like the cases are too different to work.

Sure. Still bad for the consumers who want the classic Coke though.

So, do your comparisons correctly. No matter how much you insist, Python 2 just isn't dead (or obsolete, etc.). Lack of new features doesn't imply obsolete.

Python 2 is no longer being actively developed. It receives bug fixes, and even those are scheduled to stop before too much longer. The fact that people are using Python 2 means that it's not dead, but that doesn't mean it isn't obsolete.

Think of it this way. You need a library to solve some problem, and you find one on Github. The project hasn't received any major updates in 3 years. Some people have submitted pull requests, and a few of them have even been merged, but it's clear that the maintainers are focused on other projects these days. Is that an indication that this project is simply mature and no further work is required? Or could it indicate that the maintainers want to work on other things, and this is not a priority for them any longer?

Saying that Python 2 is obsolete isn't an insult. Python 2 is popular, and loved by many, many people. It has been adopted as a teaching language by many schools, has inspired multitudes of people to learn to code, and has achieved prominence in data science, machine learning, and scientific computing. It also happens to be at the end of its lifecycle, development has moved on to Python 3, and the developers don't have much interest in maintaining Python 2 any longer.

That doesn't diminish the accomplishments of Python 2 or the people who love it. However, it does mean that the label fits.

That's because nobody (very few) use the Amiga.

On the contrary, very many, much more than use Python 3, use Python 2.

So, it's not like the Amiga at all.

It's more like as if e.g. Apple suddenly decided to stop producing laptops because "iPads are the future", and forcing these down everybody's throat.

(No, it's not related to the matter at hand, and certainly should not be taken as an attempt to further complicate this not especially fruitful wrangle. But it's a goodie and you reminded me of it so I figured I'd share.)

Clothes are "deprecated" or "obsoleted", just like everythihg else.

Here is one recent one: http://www.randalolson.com/2016/09/03/python-2-7-still-reign...

If you have counter statistics showing that Python 3.x is more popular than 2.7 I would very much like to see them.

But to be fair, even with that, I doubt you would get more than 30% of Python 3 users. Which is kinda in line with other surveys, such as the one from JetBrains. (It's probably a good guess that users of Python applications are even more conservative in upgrading than developers of Python applications.)

2.7: 10 million (M)

2.6: 0.5 M

---

3.5: 1 M

3.4: 0.750 M

3.3: 0.05 M

3.2 and 3.1 too low to make a difference.

-------

So totals:

Python 2.x: 10.5 M

Python 3.x: 1.8 M

---

Python 2.x is waaaaay ahead over 3.x

If you're going to create this abomination, at least do us all a favour and DON'T call it Python. Call it Retardython or something. I don't want to imagine people coming into the official support channels and claiming they are using "Python 2.8", then other people lecturing them about what that software really is, etc. Sounds like a horrible waste of time. (Source: I spend many hours a week helping fellow Python users.)

They could license it to Python 2.8 for free if they want to, though it seems unlikely.

Yes, the built in csv module really does that in Python 3.

If you pass it bytes, yes, it does. If you pass it strings, no, it doesn't.

If what you pass to the built-in CSV writer is not a string, the CSV writer will call str() to get a string representation it can write out. The string representation of a bytes object includes the 'b' prefix.

Meanwhile, you discovered your bug: you were treating bytes as text, which is likely to blow up on you sooner or later, and thanks to how Python now handles text, it blew up on you immediately as a way to remind you not to treat bytes as text.

What you probably think you want is for the CSV writer to realize it got a bytes object and, instead of calling str(), call its decode() method to get text it can write. But that is once again a dangerous operation, and sort of the whole point of Python 3's text changes is it won't let you get away with that stuff anymore.

It doesn't "blow up". If it blew up and retired, I would have seen the problem. The problem, like several python 2/3 incompatibilities, is that Python 3 merrily did something different, without telling anyone, until eventually we track down what has changed. I spent quite a while on this very bug myself, and it, along with others, persuaded me to switch to a different language (serious I know, but I was just getting annoyed with python's general loose dynamic nature, in combination with the python 2/3 changes.)

It's not a bug, it's a fix for an architectural error in Python 2, and it was quite well announced at the time: https://docs.python.org/3.0/whatsnew/3.0.html

But the fact that the same code now silently does the always wrong thing in Py3 wrt CSV is clearly a bug.

Actually, the design defect here is calling str() on everything, and assuming that the output is sensible for CSV. It may be a decent rule of thumb, but it clearly does not apply to bytes. Given the likelihood that someone might mistakenly use bytes as a string (for example, because they're porting a legacy Py2 codebase), this should be a hard error, immediately reported as such, and not just a silent behavior change.

Or do we say "CSV outputs strings, whatever is the string representation of what you passed in is what gets written out", and trust people to figure out when they're working with something that has a "wrong" string representation for their use case?

Because remember: the whole underlying cause of this was treating a dangerously non-string value as a string. Those bytes objects should have been decoded to strings long before reaching the CSV writer. Python 3 does raise more and louder exceptions when you pass bytes to things that expect strings, but the CSV writer isn't a thing that expects strings; it expects things that have a string representation, and several common use cases get much more difficult if you change that to force every user to explicitly do throwaway casts to string in the name of protecting people who keep insisting on writing dangerous "I'll treat bytes as string until it breaks, and then complain that the language did the wrong thing, not me" code.

So yeah, I would be fine with making an exception for it (and providing some kind of option to disable that exception, for that incredibly rare case where someone really does need b"foo" in their CSV output).

And then in 5 years, flip the default of that switch, and deprecate it. In another 5, remove it entirely.

Also, note that raising an error in this case is not placating the people who insist on using bytes as strings. Quite the opposite - it very loudly and unambiguously tells them that they're wrong, and how exactly they're wrong.

Um, this is exactly what I proposed above!

"this should be a hard error, immediately reported as such, and not just a silent behavior change."

What I'm asking for is that csv writer raises an exception if it sees bytes anywhere by default. The problem is that right now, it doesn't! It just gives you "incorrect" output, that might go undetected for a long time.

Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.

If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in droves.

My data is not misencoded, you see. It's just misunderstood.

So I won't be able to use NumPy with either of my two native languages. That sounds like a bit of a shortcoming for the majority of the world.

It could be argued that the csv module's behaviour is reasonable, and NumPy's isn't. (I'm not 100% sure about all the details of this issue) Hopefully, NumPy will change it's behaviour to match Python 3, but if not you could still use the NumPy CSV routines like `loadtxt` or `genfromtxt` [0]. So then this becomes a documentation change to add some warnings to both modules.

> they would do well to opt out. And they do--in droves.

This is simply not true. They would do well to handle strings properly and so avoid bugs in future - something Python 3 actively encourages, and Python 2 obscures. And while I can't speak for every company, our metrics show that our Python 3 code has far less customer issues than Python 2, Perl, or Ruby. Now that's business value. (Edit: I mean it's hard to make the comparison - the Perl code is e.g. older - but we're writing code now, and when the interns add new stuff to the Python 3 codebase, it breaks less. All of them are still actively developed, and the Ruby one is about as old as the Python 3 one).

[0] https://docs.scipy.org/doc/numpy/reference/generated/numpy.l...

Text encoding issues are absolute garbage in Python 3.x

I fucking hate the way that csv module works with text encodings.

As soon as I can figure out a reliable way to take latin-1 and save it as UTF-8 without breaking everything, I will try to shoehorn in a PR.

Right now, it's fucking awful. My ETL pipeline hates it, I hate it, my boss hates it, and my internal constituents hate it. Because it sucks.

A file I can read in one encoding and write as another should be readable with the encoding I wrote it in. That is not currently the case with the latest version of Python.

And it makes me hate the world.

    with open('some latin-1 file', 'rb) as f:
      text = f.read().decode('latin-1')
    with open('some utf8 file', 'wb') as f:
      f.write(text.encode('utf-8'))

If you use bytes as a string you are Doing It Wrong.

If you use bytes as a string you are Doing It Wrong.

I do that operation on a file I get from an API. I know for a fact that the encoding I'm receiving is latin-1.

I run exactly that operation on the file that you wrote out in code.

When I try to read that file back in as UTF-8, I get encoding errors. That does not make for "super good." That makes me want to scream.

I do not have this problem when I use Python 2.7.x

To be perfectly clear: bytes (b'') is not a string. Again: bytes is NOT a string. It is an array of octets, aka bytes, aka unsigned 8 bit integers. NOT characters. NOT a string.

If you are dealing with bytes that are encoded representations of a string, then you have to know what encoding they use to decode them and treat them as strings.

  in_file = open("in.csv", 'r', encoding='latin-1')
  in_csv = csv.reader(in_file)
  out_file = open("out.csv", 'w', encoding='utf-8')
  out_csv = csv.writer(out_file)
  out_csv.writerows(row for row in in_csv)

The resulting file is not readable, and it makes me want to kick puppies and punch kittens.

I don't see how silently printing a binary literal, if that is indeed what it does, is reasonable. Simply put, b"foo" is not meaningful CSV.

What it should do is 1) raise an exception by default, informing the user that they need to be supplying strings and not bytes, and 2) provide an explicit switch to treat binary data as pass-thru, which would be useful in scenarios where you're just reading a file and dumping it elsewhere, and don't want to spend time decoding and then encoding everything.

    + if (PyBytes_Check(field)) {
    +     append_ok = FALSE;
    +     Py_DECREF(field);
    +     PyErr_SetString(PyExc_TypeError, "Field is bytes");
    + }
    else {

I don't think this is the right solution. It seems weird to have a special case because people aren't watching what they're putting in. Garbage in, garbage out, consenting adults and all that.

[0] https://docs.python.org/3/library/csv.html

But "practicality beats purity".

And "errors should never pass silently"!

It's the same kind of thing that leads to safety warning stickers put on products. You may read it and think that it's something so obvious that consenting adults should know better. But then you look at the statistics about how many people did not, and realize that, yeah, a sticker along the lines of "don't stick your finger into a food processor" is actually a good idea. Especially given how cheap it is, and how expensive reattaching fingers is...

Basically, products should be designed around known human weaknesses, and that includes entrenched modes of thinking by past products. It doesn't mean that new products should accommodate those entrenched modes, especially when they lead to other problems. But they should try to detect them, and issue clear and explicit warnings, to guide the person to the proper way of doing things.

In fact, the reason I chose Python was because I was able to dive so quickly into real problems like this with no problems whatsoever.

This is a minor issue for someone porting from 2 to 3, it is not a problem with 3

Python's a superlative language but it has a pretty terrible set of included libraries. urllib2 isn't the only library with a superior alternative on pypi. Pretty much all of them do.

I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. So I'm not at all eager to move to version 3 and don't really see any benefit. Not sure if those who aren't migrating feel the same way, but I wouldn't be surprised if some of them do.

(Edit to address comment below: There are more issues I have with Python 3. It allows more bugs to slip through, for instance. I actually particularly like a comment I just wrote, so I'll link to it here: https://news.ycombinator.com/item?id=13145299 Do note that this was added after the reply below.)

I meant I don't see any benefits for me, not benefits for other people. I assumed that was clear; sorry if it wasn't.

> Unicode.

Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language.

> Async.

It's a nice feature, yeah. I can live without it, as people have for many years. Maybe if I was used to having it around I wouldn't want to go back, but I'm not.

> Extended library.

Cool! I'm not sure what exactly falls under this that I'm supposed to be missing, but pip install has sure been taking care of everything in the blink of an eye in version 2.

> Required keywords.

Cool! I need it about as much as I need a donut.

> syntax inprovements (lots of m, many more than just the removal of the print statement).

nonlocal is literally the only positive one I can think of right now that I'd actually care about. But then again, it comes up maybe 50x less often than the parentheses I have to write for print, or the tuple unpacking that I have to do. So yeah, it's hardly a reason to migrate.

> Type hinting.

Nice to have. I'm living just fine without it. Maybe I'd have migrated if it actually optimized things or did something more useful.

You should read some changelogs of past python 3 releases. 3.6, for example, has ordered dicts by default. Which is quite convenient when you need to write test testing a small dict with two items for example.

I like driving an old muscle car, most of m look beautiful and bring me everywhere i want. But damn, those new cars changed a lot and are much more comfortable. (But they do break as much ;))

https://mail.python.org/pipermail/python-dev/2016-September/...

But it is insertion order indeed, not sorting order.

I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple).

That means Python 2.7 helped me catch more bugs. Think about that!

Second, no, I just listed the two that irritated me the most every time I tried to switch, because they were the first things that came up by far the earliest and most frequently. Small inconveniences can be amplified through their frequencies. There are lots of things I don't like about it though... division becoming floating point division, having to say list(foo.items()) or list(map(...)) instead of just foo.items(), etc... again, more verbosity and typing for common cases where I really didn't mind the old way. If I wanted imap(), I could've just used imap; they could've just moved that to __builtin__ and made my life easier that way.

By the way -- the lazy nature of map(), etc. also means you catch fewer bugs now. Again, think about that! Just because it looks more efficient, that doesn't mean it's actually better. If there's anything I've learned, it's that even the smallest things tend to come with non-obvious tradeoffs.

Finally, regarding strings: if you look at my earlier comments, yes, I already acknowledged the Unicode changes were for the better. Awesome. I agree. Cool? OK, but there are other things in the language besides Unicode though, and they're not as awesome. I don't spend my entire programming life dealing with Unicode strings, so I care about other things too, and they make my life harder. Simple as that.

I'm a huge lover of Python, but I drop into C# when I need stuff like that. Or Go. Or Rust. Or something.

You're just making bad decisions here.

If you're looking to catch bugs in your code before you test or deploy it, don't use a dynamic language.

Python has never been and probably never will be a language with declarative types and the checking that allows.

Pick a different hammer if that's the nail you need to hit. Don't complain about the hammer you want to use not being a screwdriver.

In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made.

And frankly, I think if you like to use lambdas that much, you really want to program in a language where everything is an expression, such as Lisp or Haskell.

I'm glad I'm not. Otherwise I probably wouldn't be using it either. Not sure how that is my "problem".

> There are features that other people like (such as using [asterisk] in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made.

I like that [asterisk] syntax too.

> And frankly, I think if you like to use lambdas that much, you really want to program in a language where everything is an expression, such as Lisp or Haskell.

Or I could just keep using Python 2.7 which works just fine, and not move to version 3 where I'm not welcome.

It's your problem in e.g. where you want list returned by default where Python 3 returns an iterator by default. Why is that useful for many people was already explained.

> I like that [asterisk] syntax too.

Funny, AFAIK it is Python 3 only.. https://www.python.org/dev/peps/pep-3132/

> Or I could just keep using Python 2.7 which works just fine, and not move to version 3 where I'm not welcome.

You are welcome to use Python 3, but - suit yourself. :-)

Misreading comments is not helping.

I think it's unfair to say that I misread his comment - he doesn't explicitly mention he is aware of the workaround I outlined for the functions, and that he is bothered with lack of tuple unpacking in lambda expressions only, not in ordinary functions.

Regardless, I still think it's quite impolite to downvote somebody who wants to help you and misunderstands you, if they are not e.g. factually incorrect. If you don't actually tell me where I am wrong, I cannot improve my answer. Also, this is not Stackoverflow, where that could be marginally acceptable (I am very strongly against downvoting without explanation).

Well, I don't consider it a "misunderstanding" when there are literally just 2 things to note in my comment that you're replying to ("lambda" and "tuple unpacking") and you still somehow miss 1 of them. I think it totally deserves a downvote, because it makes me look stupid when you present a reasonable solution to a non-problem and make readers assume I was saying something other than I was, and on top of that I have to waste some 5-10 minutes of my time replying. That's not something I appreciate.

That said, like I said, I never actually downvoted that comment (because I obviously couldn't). So you don't need to worry about the internet points.

I admit I don't use lambdas that much, since generator expressions (which is like Python 2.3) they aren't really needed too frequently. And in most cases you're better off using function anyway, because in Python statements are not expressions, as I already also stated. For example, I use print() for debugging frequently and this is tough to insert into lambda. (And even in Haskell I prefer to name subexpressions to lambda syntax.)

> That said, like I said, I never actually downvoted that comment (because I obviously couldn't). So you don't need to worry about the internet points.

I am not worried about internet points (I actually got about 80 of them on this discussion alone, which is frankly ridiculously too much, and in practice, I find that comments I personally find to be the most insightful only rarely get most points), I am just really annoyed when somebody downvotes my comments without any explanation, because I am a very curious person and in most cases it's just a honest misunderstanding, which could be cleared up with, I don't know, actual communication?

And at least two or three other people actually downvoted my original comment, so I would like to use this opportunity to invite them to come forward with an explanation what they found so wrong about it.

  list(map(lambda (some, thing): some + thing, everything))
  # better
  list(some + thing for (some, thing) in everything)

  # okish, "verbose lambda"
  def compute(everything):
    def magic(elem):
      some, thing = elem
      return some + thing
    return list(map(magic, everything))

  # probably better
  def magic(some, thing):
    return some + thing
  def compute(everything):
    return list(magic(some, thing) for (some, thing) in everything)

Too much nonsense in your comment. Really now? How about you give a realistic example where syntactic sugar doesn't substitute for it? Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... and that's the prime example on their web page (and a realistic one at that) for where you're supposed to use lambdas: https://docs.python.org/3/tutorial/controlflow.html#lambda-e... If you're telling me this isn't Pythonic, you're really just not being sensible.

I suggest you look at namedtuple: https://docs.python.org/3/library/collections.html#collectio...

I think you should watch some Raymond Hettinger's talks, he is discussing many little things like this.

This has been the general trend in mainstream languages lately, not just in Python. E.g. in C#, all LINQ operations are lazy. in Java, the new stream API, to be used with lambdas, is lazy.

In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). The new APIs are more straightforward to use.

The reason to change the behavior of an existing API is because the default (i.e. most obvious) API should also be the most flexible, and do the right thing in as many cases as possible. This was not the case with map etc in Py2.

The disadvantage of changing an existing API like that is that it breaks code. But Py3 broke code anyway, so it was a good time to introduce breaks like that for the sake of better defaults.

Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence.

> In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them).

This is going on a tangent but LINQ still has hoops to jump through. You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import *" and then using imap, which you could've always done.

Yes, it's what I had in mind. I have to admit that I completely forgot about ConvertAll (and so assumed there was no map).

I think the biggest reason why those weren't all that commonly used in practice, is because in .NET you often deal with opaque collection types (like ICollection<T>, or ReadOnlyCollection<T>, or even custom-made collections pre-generics) that are usually exposed on properties of objects. Since the concrete type is not known, you can't do List.ConvertAll etc.

This, by the way, is another point in the favor of lazy implementations - they don't care about input type, because the output type is always "lazy sequence". Of course, you can have an eager map similarly not care about input, but then what should be the type of its output collection by default? No matter what type you choose, someone will complain that they wanted someone else. Given Python's preference for explicitness, such design would warrant several functions like map_to_list, map_to_tuple, map_to_set etc. But, of course, if you have a lazy map, you might as well just write list(map(...)) etc.

> You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import " and then using imap, which you could've always done.

It's a bit different, though. When you import itertools, it brings all those functions into your global namespace. But when you import System.Linq, it only brings one static class into your global namespace; the actual functions are extension methods that only show up on the types to which they are applicable. So the resulting namespace pollution is far less in C#.

There's also the issue of import being generally frowned upon in idiomatic Python, largely because the way conflict resolution works there (silent override). In C#, if you happen to have clashing identifiers from usings, it'll prevent you from using them unqualified, so there's no good reason to avoid it.

You mean print functions. I love the new change because you can pass "print" around like any other function now, letting you write code like:

  def my_map(data, func):
      for item in data:
          func(item)

  my_map(dataset, insert_into_database)

  # For testing
  my_map(dataset, print)

If your software is being actively maintained, it's time to move to Python 3.

Maintenance is key. Most people don't stick around for 20 years anymore either. I know I'm going to have an easier time finding a new hire for a Python codebase. And he's going to have a far better chance at understanding said codebase. Code which nobody knows how to maintain will hurt us either with a fiendish bug, or limit out growth. So for me, slowly moving away from legacy stuff is good business value in the long run.

Remember, you can never be sure that Fortran code is 100% bug free. The test of time is as good as any other test, but not perfect.

(FWIW, I'd probably write most new numerical code in Julia rather than Fortran 20xx, and either call into existing Fortran via FFI, or drive it from the command line with some scripting language.)

SciPy has Fortran code under the hood: https://github.com/scipy/scipy/search?l=FORTRAN&utf8=%E2%9C%...

Both SciPy and NumPy use LAPACK - a Fortran library. SciPy also uses BLAS - another Fortran library.

So every time you praise Python for being useful for scientific work, you're actually praising Fortran and C libraries/modules wrapped in Python.

However, I recently had a gig working in py3. Apart from screwing up every single print statement for a long time, it was entirely drama-free, and actually pretty great. There really is a difference between living and dead languages I think. 2.7 is the latin of python.

A lot of people here have strong opinions about the name "Python 2.8". I don't mind changing it, and intend to do so, (https://github.com/naftaliharris/python2.8/issues/47). I picked it initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names!

For those of you with 2.7 codebases or projects, I'd be extremely interested in hearing about whether you were able to get this interpreter to run your code. Personally, the biggest challenges I've had so far are with dependencies that check for `sys.version_info[:2] == (2, 7)` as opposed to something like `sys.version_info[0] < 3`. But I'd be very interested in other people's experiences, particularly with larger codebases.

[1] A minor and somewhat pedantic point: The interpreter I've been working on includes PEP 515 (underscores in numeric literals), which is new in 3.6. I didn't think it was right for me to "take credit" for this new feature before it was even out in Python 3.6. Obviously, the real credit for this feature existing (in 3.6 or in any interpreter) goes to the CPython core devs, and especially Georg Brandl.

Keep up the good work, this could help a lot of people!

What if more than one person did that? (paraphrasing Raymond Chen's "What if two programs did this?")

There can be only one official Python 2.8, but since it will never exist (see PEP 404), there can be many unofficial mutually incompatible "Python" 2.8 implementations. Therefore, calling it "Python 2.8" is a bad idea.

So the question is do you want to basically light that money on fire, or just keep your perfectly fine Py2.7 code running and maintained another few years.

More discussions of the monetary value of programming languages please. What is "correct" or "right" isn't all that interesting to many, for good reasons.

Kudos to this project and hope it can set us on a saner migration path to Py3. (Should totally change the name though.)

Honestly, the level of self-entitlement through all 2vs3 threads is staggering.

But I do mind people saying in these discussions "you should all move to Py3 now or you are stupid/evil".

No. There are legitimate reasons for staying with Py2.7 and embracing it.

So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends.

Is that self-entitlement in any sense?

All I want is for people who I think have a huge blind spot to stop calling me ignorant for decisons I make about MY code. I totally don't expect core CPython devs help me out though.

It's not just CPython, it's the Python specification of which CPython is the reference implementation. The specification couldn't move forward in significant ways without making some of the changes that came with Python 3.

> All I want is for people who I think have a huge blind spot to stop calling me ignorant

The level of vitriol in 2vs3 threads has been way too high from the start, because people always hate change. You are obviously free to do what you want, you always were. Don't mind the haters, but please don't be one either.

It has already been explained elsewhere in this discussion by other people, I would strongly advise against that. If you for whatever reason have to stay on 2.7, then make sure your new code is 2.7 only (and best if it works with 3 without changes if you decide to change your mind later).

Consider what's more likely in the far future (after PSF will give up on 2.7 support in 2020). That somebody will support 2.7 as it is, or that this guy will support his Python 2.8 hybrid?

Also consider what happens (in the far future) when some library you use will drop Python 2 support. It's not likely it will be easy to run on this Python 2.8 hybrid, either.

And if you for any reason must use Python 3 features in your code base, just bite the bullet and port it.

My py2 code uses unicode properly which may color my view a bit...

But I don't really disagree with what you say.

(Looking at this from the perspective of the "Python Community" or someone who's goal is to adopt Python3) His focus is to back port newer Python 3 features developed since then. Does this help people move to Python 3?

Good on him for digging into cpython. While there's __future__ and the backports module, he seems to have focused on features that aren't just new libraries (which is cool). A few years ago I was trying to backport Python 3's Namespace Packages for my company since our internal import tools effectively do the same thing (except our's had bugs).

[1] https://docs.python.org/dev/whatsnew/2.7.html#the-future-for...

It is very dishonest to call it Python 2.8 then.

Shoot the 2.8 messenger all you want for choosing to call it Python 2.8, but don't dismiss the issue that drives thoughtful people to get value out of this strategy.

I guess the intention was a bit different: he wanted to have stackless features in python. It's not clear to me the reason he decided to back down, whether because of licensing issues or just because the other python developers didn't like it.

[1] http://www.stackless.com/pipermail/stackless/2014-January/00...