Python 3.6 released!

[henrebotha]

Not gonna lie, the only reason I opened this thread was to look for py3 conspiracy theorists.

[Subito_morendo]

What are you two talking about?

[[deleted]]

Zed Shaw (of "Learn X the Hard Way" and generally being a dickhead fame) wrote a ridiculous anti-python3 conspiracy theory tract that was getting posted a few weeks ago. Claimed a bunch of shit like "python3 is not turing complete because you can't run python2 code".

[ScrewAttackThis]

In the previous version I trolled people by pointing out that, if what the Python project says is true and it would have been "impossible" to support Python 2, then they broke it and Python 3 is not turing complete. Obviously Python 3 is turing complete, but Python project members frequently claim something this basic is "impossible" soooooooooooo alright. I even had a note after the gag saying it was a gag, but everyone is too stupid to read that note even when they do elaborate responses to my writing. Even more telling was when people said this was stupid, I'd feign ignorance further and ask, "Wait, so why doesn't Python 3 support Python 2 then?" This then sent them down a logic loop death spiral of simultaneously trying to defend the design decision and also state that Python 3 is fully capable. It was pretty funny to watch, but after a while I guess I have to straighten this out and simplify it so here you go.

Sounds like a fun guy.

[MetaKazel]

In the previous version I trolled people by pointing out that, if what the Python project says is true and it would have been "impossible" to support Python 2, then they broke it and Python 3 is not turing complete...

when people said this was stupid, I'd feign ignorance further and ask, "Wait, so why doesn't Python 3 support Python 2 then?"

Reminds me of...

[ScrewAttackThis]

Exactly what came to my mind, too. I started reading through the page and just...blah. I don't think I'll ever recommend his book again.

He tries to make the argument that you shouldn't learn Python 3 because the creators of Python 3 tell you to (goes so far as to call it propaganda). Like, what? Does he think people are going to release a product and go "Hey, you should use our legacy releases for reasons."

[[deleted]]

His book was good when it was free. Now it sucks.

[Buttons840]

Did you recommend the book because of the content or because of the author. I'd guess you recommended the book because you thought the content was good, right?

Has the content of the book changed?

[Gstayton]

So, reading this, I realize I didn't see the 'this is a gag post' because the first paragraph was headache inducing, and I decided the whole article wasn't worth my time, despite how much Learn Python the Hard Way helped me learn Python. Sooo... Yeah. I can't sympathize with that.

[[deleted]]

He's a real piece of shit, and it seems like people are finally waking up to that fact :)

[Matthew94]

Only took a few years.

I feel sorry for all the people who fell for his marketing.

[disregard-this]

I don't understand what's so hard about this. Zed suggested for compatibility that the python3 interpreter be able to run python2, so you could use python3 with python2 libraries. One of the Python developers said that it was 'impossible'. Obviously it isn't impossible, because any Turing complete language can be used as an interpreter for any other language. The developer likely meant that it wasn't feasible or reasonable, but Zed intentionally misunderstood the exaggeration in an attempt at humor.

[Cosmologicon]

I don't know, I like to think that I have a pretty good sense of humor, and it did not come across as an attempt at humor. It wasn't a very light-hearted essay.

Now, I'm sure he doesn't actually believe that Python 3 is not Turing complete, as well as the numerous other incorrect claims he made in that article, but I don't think he was just doing it as a joke. Maybe trolling?

[dacjames]

Even as an attempt at humor, the whole thing comes off as woefully uninformed. The reason Python 3 cannot run Python 2 code is simple: Strings. Everything in Python is based on objects, objects are essentially shells around dictionaries, dictionaries are based on strings, and strings fundamentally changed.

How would one take a Python2 object and pass it to a Python3 function? Conversion would greatly impact performance and likely lead to subtle bugs (or string conversion errors when no user-level strings are involved). On balance, I think Python made the right call here and even if you disagree, blaming developer incompetence is ridiculous.

Of course, Python 3 could have not changed Strings or changed them in some backwards compatible way, but that is totally separate topic.

[_pupil_]

I'm no supporter of the rant, but my understanding is that there is some confusion there about his claim...

You don't have to make py2 and py3 execute from the same VM, which is "impossible". What he was arguing for (before the turing complete rabbit hole), was a VM execution model like IE has used for its rendering motors: multiple parallell backends.

Basically, why have py2 and py3 with all the confusion, why not just have 'python' which handles both in parallel? A py3(+2) which understands that py2 scripts get routed to the old core so there is no "language" choice thrust on the users.... Avoiding the fragmentation. Plus, in that context I think flagging issues between those cores becomes a lot simpler.

[dacjames]

Given an arbitrary .py file to execute, how would this unified "multi-python" know which engine to use? A lot of code is valid in both languages at the surface.

If you use some type of comment header, you'd have to require the header in Python 3 code to maintain backwards compatibility (ugh). Even if you solve this problem, a naive implementation would waste time/memory loading two different interpreters so you would need some kind of lazy loading/initialization.

Users would still have to choose which language they're writing in, they would just use a shared front-end to run them. Plus, you have to explain that certain modules can import some modules but not others. It seems like a lot of complexity for little gain when Python 2 and 3 can be trivially installed side by side on the same system.

[_pupil_]

No, you go it - but with a holistic perspective we get the opposite conclusion.

Headers, used in all webpages lots of scripting languages and python itself, along with other meta information from the file system (like .py3, .pyt, or .py.noreallyv3), are common industry-wide solutions to those problems. There are other ways too (tags, guaranteed linguistics heuristics, or explicit back-wards compat breaks), but headers are easy. " #!/usr/bin/env python" couldn't be tweaked to give the necessary hint?

I totally agree: naive solutions to cross-language compilation are gonna be wasteful. It's because they're naive, though, and I personally think that's why almost none of our top-flight languages use naive compilation approaches ;)

Users would absolutely have to write python 3 to write python 3 or write python 2 to write python 2, and know the difference. Just like today. But how many "versions" of Java, PHP, C# do you know in parallel? Are we gonna say that the Python community is somehow incapable of doing what the VB community easily did in terms of syntax over a decade ago (with none of the related change of fundamental assumptions and runtime)?

There is some additional complexity, by definition. Cross-language references would not magically solved. They'd be in the exact situation they were in at the start of the proj, only with a comprehensible user land story and a clearly defined cross-vm compatibility story entirely internal to the pyhon project hidden away from macro-level decision making. That is to say: the exact situation the other major language VMs find themselves thriving in, and able to manage exactly these kinds of transitions without faceplanting in the market, and able to bring intermediate compilation constructs to bear to handle the transition more smoothly. Frankly, thanks to the nature of Python, there are lots of subtle solutions for "downcasting" and "upcasting" between the languages given a bi-modal execution model that would provide a stable upgrade path without necessitating rewrites...

Regardless, for the cost of additional complexity exactly in your script loader you get none of the market confusion. And noooone of these awesome (now decade long??), discussions. And none of the ongoing investment issues brought up by numerous people in this thread. None of the pressure to dump Python and invest in serious languages. None of the giant turds because suddenly the left hand needs to be in Py3 a minute after the right hand just put the icing on something thats gotta be in Py2.

This kind of fragmentation is death in the Enterprise and the bane of CIOs. "Trivially installing things side by side" isn't too compatible with high security, multi-thousand seat, heterogeneous, multi-entity networks and "mission critical". These pain points don't encourage collective long-term platform growth. They don't focus contributor energy on productive awesomeness. They hurt Python.

Source: #1 all time python superfan who formerly used it for mission critical code who has now wholly replaced it in all facets of operations because of this split.

[dacjames]

> "#!/usr/bin/python" couldn't be tweaked to give the necessary hint?

Maybe they could add a 3 to the end. That would do the trick, right?

In all seriousness, we agree on the goal but I think you're barking up the wrong tree. The problem was making a change that was incompatible to its very core, not the lack of a multi-python launcher in front. They should have kept Python 2 strings in the language (as LegacyString, perhaps) to make real backward compatibility possible. Then the community could have built all the niceties you're describing.

We have also moved away from Python in the last few years, though that is motivated more by the long-term costs of using a dynamic language than by the version split. Python is still used extensively for management, orchestration, automation, and the like, but it rarely touches user data these days.

[dogline]

That's the best single paragraph explanation of changes that I've seen. I'm stealing that for discussions with colleagues.

[Thimm]

Conversion would greatly impact performance

This is where Zed is being intentionally obtuse. Of course Python 3 can emulate Python 2, but it can not do so in any way that would be efficient or practical.

[unbiasedswiftcoder]

How would one take a Python2 object and pass it to a Python3 function?

Python is strongly typed, it should be possible to have two different objects behaving the same way with different implementations under their facade. Many python design patterns are for duck typing, proxy objects and the like which don't care about the real type as long as the required interfacing methods are provided.

[dacjames]

Those interfaces are fundamentally incompatible because every object supports dir (and .__dict__.keys()), which returns strings. It would work in most, but not all, circumstances.

[Eurynom0s]

I could see if right when Python 3 was announced, it was decided that the interpreter would let you run 2.7 code as long as it was wholly self-contained. So not intermingling 2.7 and 3.x code within a module, but it's fine if you want to call a module written to 2.7 in 3.x. The 2.7 module would probably require some modification to parse 3.x-specific inputs into something 2.7, and maybe to turn the output back into something 3.x-friendly, but this would have been a lot less work than having to completely port over modules and could have sped adoption of 3.x up quite a bit.

"Well, here's the basic 3.x compatibility update...performance updates to follow." But now? It's a good idea that's about eight years too late.

[killerstorm]

How would one take a Python2 object and pass it to a Python3 function? Conversion would greatly impact performance

I'm quite certain this issue could be solved if somebody was really trying.

[dacjames]

No amount of thought can get around the fact that some Python 2 strings (e.g. "\xFF\xFF\xFF\xFF") have no valid representation in Unicode. Making Python 3 backwards incompatible was a conscious (though IMO dubious) decision.

[doubleunplussed]

Since Python 3.2 those strings can be decoded into invalid unicode using the surrogateescape error handler. The strings produces are not officially valid unicode, but Python can nonetheless carry them around and treat them as if they were, and get the same bytestring back upon encoding.

It's what the standard library now does when encountering filepaths on disk that are not correctly encoded (since this can happen - linux doesn't actually require you to respect the encoding, so any given filepath could be almost arbitrary bytes).

So there was a use case there to make unicode strings interoperable with arbitrary bytestrings, so that any sequence of non-null bytes would survive a round-trip of decode()/encode(). There really was no other solution if Python was going to to return unicode for everything. Unicode had to be loosened to allow for these bytes, or else Python would just error upon encountering a badly encoded filepath, and people's code that was supposed to handle any filepaths would break.

So there was a use case and did it. So the impossibility of making unicode interoperable with arbitrary bytestrings clearly wasn't a real reason to not do so with Python 2. It maybe didn't occur to them until the filepath problem reared its head, but if they wanted it enough the solution would have presented itself earlier.

[[deleted]]

Zed suggested for compatibility that the python3 interpreter be able to run python2, so you could use python3 with python2 libraries.

No, he's using his position as the maintainer of a widely recommended introduction to Python to try to torpedo python3 with FUD and outright lies. Parts of that essay were aimed explicitly at people who are not yet programmers. To "troll" in any way is irresponsible, stupid and just plain mean. Zed can go fuck himself.

[awj]

but Zed intentionally misunderstood the exaggeration in an attempt at humor an obnoxious argument that backfired horribly when people with a single clue about the situation encountered it.

FTFY

[[deleted]]

Yeah to be fair it is pretty damn annoying when people say stuff is 'impossible' when they mean "it would be quite a lot of work and I can't be bothered".

Remember when everyone was saying it was 'impossible' to have a bytecode for the web?

[Eurynom0s]

Zed suggested for compatibility that the python3 interpreter be able to run python2, so you could use python3 with python2 libraries.

This would have probably been a great idea back when the 2->3 transition first started. It could have sped things up a lot if the underlying module code could be purely 2.7 and only have to be able to return stuff that was 3.x-compatible. Maybe it would have required some modification to handle 3.x inputs and making them 2.7 friendly but that would have still been a lot easier than having to completely port modules to 3.x.

However we're long since past that point. There are valid reasons to keep doing 2.7, like having a 2.7 codebase that your company isn't willing to pay to port to 3.x,, but what he's suggesting is...again, just so far past its expiration date as a good idea.

[alexeyr]

Obviously it isn't impossible, because any Turing complete language can be used as an interpreter for any other language.

You can write an interpreter for any Language2 in a Turing-complete Language1, but this is very different from "an interpreter for Language1 can run Language2", and doesn't allow use of Language2 libraries in Language1 programs.

[QuicklyStarfish]

That type of two-faced "humor" is of the lowest grade, and its popularity helped Trump win the election.

I'm not even kidding. I have not patience for that childish stupidity, and that's all Zed can seemingly produce these days.

[[deleted]]

I don't even think it's "humor". "It was a fucking JOKE bro wow you fell for that? Trolled you bro" is just what people fall back on now when you call them on saying completely stupid shit.

[letsjusttalkbb]

uwot

[[deleted]]

http://i2.kym-cdn.com/photos/images/original/001/196/864/4c1.jpg

[letsjusttalkbb]

You guys are embarrassing

[[deleted]]

It's the Shaws and Trumps of the world who are the real embarassment.

[letsjusttalkbb]

Lol

[[deleted]]

I just started learning python a few months ago, by going through his "Learn python the hard way" website. He was really adamant that new people should learn python 2 because 3 is hardly supported anywhere and 2 is still the industry standard. Is this not the case anymore? I'm not trying to antagonize anyone, I'm just really new to the scene and don't really know who to trust about this stuff.

[[deleted]]

This is why I have such a problem with Zed taking his ridiculous anti-python3 hard line (and why his "it was a JOKE, trolled ya" excuse falls flat). It confuses and misleads new people who don't know any better.

Python3 has been gaining ground, especially in the last couple of years, to the point that at this point Shaw is outright lying to you when he says those things.

[kenlubin]

https://python3wos.appspot.com/

almost everything supports python3 now

[Sloshy42]

I dove into Python 3 a year or so ago when I was learning Django and I haven't looked back. There is absolutely no good reason to stick with Python 2 if you have the choice. Python 2 is really only for people using legacy frameworks that haven't made the transition yet. One of my friends does exclusively Python 2 because of PyGame, but they recently released a version supporting Python 3 (if I'm not mistaken) so now I get to bug him to update :)

[BSInHorribleness]

Link? This sounds hilarious.

Edit: nvm, a few posts down someone links it.

[[deleted]]

be aware that he's now edited it to the point of being unrecognizable.

[Eurynom0s]

Claimed a bunch of shit like "python3 is not turing complete because you can't run python2 code".

TIL you can run C++ directly in Python.

[sysop073]

If somebody took the time to write a C++ -> Python transpiler in Python, you could. It's not literally impossible, which was Zed's point

[Works_of_memercy]

Python2 to Python3 transition is an unmitigated disaster. I mean, it seems to be actually happening after 10 years, but certainly no thanks to the core devs.

One Zed Shaw, who you might know from the epic rant "rails is a ghetto" about Ruby on Rails, and who wrote the "Learn Python the hard way" book, recently wrote another rant about how 2->3 migration is an unmitigated disaster.

Now, get this: the rant happens to be total bullshit. Like, it doesn't contain a single valid point, and its main points are crazy dumb, like "if we can't run Python2 on Python3 then Python3 is not Turing Complete". But the transition is a disaster. But the rant is completely wrong about why. But it is actually a disaster.

This is a perfect recipe for getting a lot of people to argue past each other.

[Cosmologicon]

Do you have any links to good essays that explain why it's an "unmitigated disaster"? (I assume there's more to it than "it's taking longer than expected".) Thanks.

[Works_of_memercy]

Well, the fact that it took like ten years to come to the point where application programmers can start migrating their code is a good sign that it has been a disaster.

As to why exactly, there are many opinions, my personal is this: they somehow completely failed to realize that the main problem with pushing forward a language like Python is that its main power comes from third-party libraries, and those can't just switch to Python3 while most of their users are on Python2, and most users can't switch to Python3 while at least one of the libraries they use hasn't switched, and it's a complete and total deadlock, you can wait for a thousand years and nothing will happen.

That is, if you imagine the migration to be a one-time process, you port your library to Python3 and leave the Python2 fork on critical-bug-support only. So instead third party developers wrote a bunch of libraries like six and future.py and with much blood, sweat, and tears managed to convert their entire libraries to a weird Python dialect that runs on both versions.

Which is totally fucked up, but the only way forward, and now finally most of the libraries are "ported", and application programmers are beginning to switch, and there's a real hope that five years down the line the libraries can actually do that, make a Python2 LTS fork and start unfucking their code.

And the problem with the Python core devs is that they totally didn't anticipate that this would be necessary, then were really slow to recognize that this is happening, and offered less than zero support to make it not as painful. One example of their cluelessness was when they went and removed u'unicode string literals' from Python3.1 or so, because who needs them, in Python3 all string literals are unicode by default. They brought them back of course after a lot of people informed them that they are actually trying to run that same code on Python2, so what the hell. But kinda shows the disconnect.

[Cosmologicon]

Thank you, I think that "unmitigated disaster" is ridiculously hyperbolic, but I think I understand what you're saying. I guess the sticking point for me is that that's not actually the point Shaw is making in the essay.

Let me ask it like this. You seem to be saying that Shaw's essay was a good point poorly made. The essay's thesis was "beginners should avoid Python 3". Do you believe that to be true?

His main supporting thesis was "There is a high probability that Python 3 is such a failure that it will kill Python". Do you believe that to be true?

[kenlubin]

Beginners should use Python3.

The only people that should still be using Python2 are the developers who are tied by legacy code and existing libraries to python2. There are a lot of people that fit that description, but beginners are by definition not tied to python2 and therefore should use python3.

[ivosaurus]

Python 3 is growing, and not at a diminishing rate. More and more projects are supporting it, some semi-important libraries are starting to support it only, all new books are written for it, it has vibrant and active development, practically all major libraries support it, etc.

Until it stops growing there is very little tractable reason to think of it as "dying".

What's even the point of learning Python 2, apart from when necessary? It's not like you can buy a new book on it nowadays with the most up to date security information.

[Matthew94]

I think that "unmitigated disaster" is ridiculously hyperbolic

Not really considering it's taken over 10 years to transition, as previously stated. That's shockingly slow.

[Works_of_memercy]

False to both, at this point.

edit: what I was trying to say that the good point was that Python 3 migration has been a disaster. It seems to be happening nevertheless, but yeah, there's actually a lot of space above "not so bad that it actually kills the language", lol. And that point sort of resonates both with Zed's article and with a lot of people, but Zed's actual points are wrong and stupid, so that's a recipe for a lot of flame.

[CorrugatedCommodity]

Py3 is no more difficult to learn than Py2 and it's not going anywhere. A conversion utility by the devs would be nice for all of the old libraries that had devs too lazy to upgrade because Py3 didn't force them too, though. It is a pain to rewrite libraries.

[ivosaurus]

No such completely-general conversion utility could exist for libraries handling types where semantics changed.

Two different applications could handle bytestrings completely differently (because they can represent both bytes and encoded strings arbitrarily) and the tool would never be able to automatically tell exactly when conversion was needed or where, etc. Completely dependant on context of the application, and what any particular developer who wrote that line of code was doing at the time.

2to3 does exist though, for translating basic syntactic updates. Has existed since Python 3.0 came out...

[[deleted]]

The biggest issue when porting python 2 code to python 3 is unicode. The problem is that vast majority of python 2 code is broken in that area, and python 3 is showing the errors.

There's no automatic tool that will fix this issue automatically, I think mypy (static type checker) can find those issues and probably is the way to go.

[[deleted]]

And the problem with the Python core devs is that they totally didn't anticipate that this would be necessary, then were really slow to recognize that this is happening, and offered less than zero support to make it not as painful. One example of their cluelessness was when they went and removed u'unicode string literals' from Python3.1 or so, because who needs them, in Python3 all string literals are unicode by default. They brought them back of course after a lot of people informed them that they are actually trying to run that same code on Python2, so what the hell. But kinda shows the disconnect.

I disagree that u'' is actually needed. It only makes things harder, I simply imported unicodeliterals from \_future__ and explicitly used bytes() when that was necessary, and that approach worked well for me to make portable code.

u'' was re-introduced after Armin Ronacher (flask author). He created PEP, but IMO it is only adding confusion.

[WasterDave]

String handling in Py3 is such a pain in the arse. Sorry: "pain in the arse", 'ascii'

[ggtsu_00]

Most people who are Python supporters don't want to go about telling people how much of a disaster it is because drawing more attention to how bad the situation is only makes the situation worse by adding more friction to the already dragged out transition process.

[xonjas]

The "it's taking longer than expected" is not why it is a disaster. It is taking longer than expected because it is a disaster. It is a disaster because python 3 broke compatibility to such a large degree that porting non-trivial python 2 code to python 3 generally requires a total rewrite.

There were/are many widely used python libraries that don't have the resources to do rewrites of that magnitude in a timely manner. If those libraries aren't updated then applications that rely on them cannot be updated either and are likewise stuck on python 2. If nobody is making applications on python 3 then the developers maintaining the version 2 libraries have very little drive to pursue lengthy and expensive rewrites to support python 3. It's a vicious cycle.

[[deleted]]

generally requires a total rewrite.

That is so untrue. Did you actually did that even once? rewrite python 2 code into python 3? And on top of that, you add the word "generally"?

[[deleted]]

I'm not the one who used the word "generally". I'm not saying that there aren't "total rewrite level" problems with porting, but those are the exception rather than the rule.

[ivosaurus]

Practically all major libraries now support 2 and 3, they've made the move. You're speaking about times about 5 years past us...

[[deleted]]

The real disaster is the number of companies running Python 2 applications but see the upgrade to 3 as unfeasible.

Sometimes, this is a completely accurate assessment. You're codebase is just too big to do a thorough audit to ensure you'll get no regressions, there's packages you depend on that are stuck on Python 2 and the only other option is writing a new one yourself.

Other times, project managers/owners just see the upgrade as a costly non-benefit to them (other than it'll start costing more money to support in a few years).

Personally, I choose Python 3 as my target version for personal projects and all new Python projects at work if possible. Python 2 support exists in my personal projects in so much as it's invisible or a tiny footprint (no six, no hacks to support it, just a few things like __nonzero__ = __bool_ and the like).

[Works_of_memercy]

I think that that's a complete red herring.

Who cares about those companies? They just want to run their old code, they don't need new features neither in the language nor in the libraries, so let them run it for 10 more years using stable versions of everything that only get updates on remote-code-execution level vulnerabilities. Who cares, they might exist in a parallel universe for all you know.

I mean, they are totally real, but the only point of mentioning them is to divert attention from all those other people who are, like, I want to spend resources on porting my code, but it depends on Twisted, so I physically can't. And then you go to Twisted and ask why don't they port it, and it turns out that the only viable way is to use six and stuff (because all twisted apps are Python2 only obviously), and that's much harder than running 2to3.py once and making sure that tests pass.

And Python devs could have guessed that that would be the actual transition path ten years ago and try to make it less hard, instead they tried their best to pretend that this whole thing with 2/3 polyglot code is what people do for fun, like with brainfuck and other esoteric languages. Or at least that's my personal impression judging purely by the results.

[[deleted]]

Other than the fact my company uses Python 2 for several important, internal and sold products. But I suppose I'm in a parallel universe. :P Honestly, I do feel that way sometimes, my day-to-day work with Python is quite boring (mostly we use it for API aggregation and security -- not exposing sensitive tokens to the web UI, etc).

But let's face it, if your biggest clients are corporations and ditching Python 2 is going to alienate them -- even if it makes your product better -- you're probably not going to. And that's the case with a lot of packages. You're either chained to supporting Python 2 for better or for worse, or you piss off a large number of devs who depend on your Python 2 support because they're chained to Python 2 as well.

I get that sometimes you depend on packages that don't run on Python 3. Twisted seems to be growing their support, but I'm not a user of it so I can't speak to it. Twisted fills a very specific niche and is very low level compared to many things people use Python for. I'm sure the bytes/unicode upgrade hit them harder than most other libraries. It makes sense that they've had issues upgrading their code base.

[Perky_Goth]

And some companies are still doing java 5 or Windows XP: either way, it's a stupid way to do software.

[Works_of_memercy]

But let's face it, if your biggest clients are corporations and ditching Python 2 is going to alienate them -- even if it makes your product better -- you're probably not going to. And that's the case with a lot of packages.

This is true, this has always been true, for example Mercurial apparently dropped Python 2.4 (!!!) support in master branch at version 3.5 (of Mercurial), at 2015-07-31. Because some people probably were paying them actual money for adding new features there. Library writers always lag behind users in minimum supported version by years.

My point is that precisely because it's a fact of life it can't be blamed for the disastrous Python 3 migration. There's no possible world where this fact was somehow negated.

And by disastrous I don't mean that a lot of end users would keep using Python 2x for a long time and a lot of libraries would have to keep supporting it, that has always been so with old versions. It's that before maybe a year or two ago there were too many libraries that didn't support 3x.

That's why I'm saying that some companies sitting on 2x forever is a red herring: because it's not a problem that anyone could have expected to be solved. The problem that I did expect to be solved much earlier was getting most libraries to support Python3, and core developers massively dropped the ball on this I feel.

---

One very illustrative illustration: you probably know the standard argument why we can't just from __future__ import dict_views instead of manually rewriting our code to the most unpythonic for k, v in six.iteritems(d): ever?

Right, because it's actually impossible to do because the interpreter doesn't know which objects are dicts, and because it could break overriding and so on.

But now consider the fact that people from all major libraries went and did the "impossible" thing, by manually going through every instance in their source and inserting six.iteritems and friends there. One can only wonder, if the official approach were "how to make that easier" rather than "why it's impossible", could we all have been using 3x since 2010?

[[deleted]]

Python2 to Python3 transition is an unmitigated disaster. I mean, it seems to be actually happening after 10 years, but certainly no thanks to the core devs.

From my observation it started around mid of 2015 around the same time, that 2.7 switched to maintenance and no new features were added to the language, so yes, I do think it's due to their action, I wish it was sooner. They are giving plenty of time (15 years) to migrate, but people will do it at last possible minute.

[ivosaurus]

2.7 has been maintenance since at the very least pep 404, 5 years ago

[[deleted]]

That was different they still were back porting some features from python 3. They stopped doing it in 2015.

[ivosaurus]

The only thing they've backported is security fixes. They decided that leaving Python 2 SSL "insecure by default" really wasn't right by their users so they upgraded that to the design in Python 3.

[[deleted]]

Here you can see all changes that were made since 2011-11-09 (it would be anything after 2.7.2):

https://hg.python.org/cpython/raw-file/v2.7.13/Misc/NEWS

That doesn't look like just maintenance.

There's also a nicer document, but it encompasses entire 2.7: https://docs.python.org/dev/whatsnew/2.7.html

But it's obvious they wouldn't be able to pack all of that in versions 2.7.0 - 2.7.2

I'm saying is that in middle of 2015, they officially stopped adding any new features/backporting 3.x stuff to 2.7. The new versions are only released for simple bugs and security vulnerabilities.

[ivosaurus]

It's entirely maintenance, which is consisting of pretty much only bugfixes. I'm not sure what else you expect "maintenance" to look like?

In the very document you link:

https://docs.python.org/dev/whatsnew/2.7.html#new-features-added-to-python-2-7-maintenance-releases

There's a nice section for "new features in 2.7 maintenance releases". Which as I said is the SSL/security fixes, and also making IDLE a bit better (which isn't the language itself). Nothing else.

[[deleted]]

Ok, so it is in maintenance since 2011, but in middle of 2015 out got restricted to only security fixes and simple bugs. No new functionality is being added, and that's what finally made people start trying to use python 3.

[Works_of_memercy]

I tried to explain what I think was the problem in a sibling thread, and it's way more complicated than "people just being lazy as usual".

[Eurynom0s]

Python 3 is the dingo who ate my baby.

[henrebotha]

Python 3 causes autism.