- [ ] I've been developing with Python 2 for 8 years now, and I take umbridge at the upgrade. Python 3 introduces a variety of breaking changes but in contrast

- [ ] I've been developing with Python 2 for 8 years now, and I take umbridge at the upgrade. Python 3 introduces a variety of breaking changes but in contrast to other comments, this is great. Python 2 has a litany of mistakes in it (ever try a listcomp using a previously declared variable name as the intermediary? Watch that get clobbered when block-level scoping decides it doesn't fancy it; there are many more similar examples), some of which are mercifully fixed in 3. For me though, what's the point? I like that lru_cache is a convenient decorator rather than having to roll my own memoisation and that some relatively solid steps have been made towards async programming but that's about it. Its not like the changes were things that couldn't be achieved before (Twisted is solid, from what I have seen so far). I still have to factor in the GIL if I want performance to a certain point (dual core processors have been around for almost two decades now - I am starting to question why cPython is even considered a serious choice for use cases where prod has more than one core). More crucially though? The APIs. camelCase features heavily (in spite of PEP8), the principle of most surprise is rampant (I recall last week discovering a function signature with infinite arity rather than passing a collection, like, you know, every other Python method) and SO many more warts. When interacting with a file, try and guess what you want: "readlines? Doesn't load each line into collection, which is what you'd expect. writeline? Be sure to manually interpolate a \n because in contrast to the name, it's actually going to insert everything on the same line because... well, who knows. writelines? Well, you know how in Python you usually iterate over over thing and handle it? Well here, you pass a collection. There's a corresponding read meth... No there isn't". If we're introducing breaking changes, how weren't these things fixed? You either commit to breaking changes or you don't make any - py3 trod the line somewhere in the middle and is paying for it with its adoption numbers. The broader point is that this mess is exactly why we all love libraries like requests. If Python were a Fortune 500 company, GvR would have been ousted as CEO long ago, and rightly so. As a contractor, I have to absorb this new way of doing things in case I find a job that actually requires Py3 knowledge (in the UK at least, these are less frequent than HN prefers to make out) because my marketability depends on it. That said, although I'm currently contributing to Pypy, I realistically see my future in Clojure, Ruby, Elixir or some other language that I'm prepared to put the time into picking up, in contrast to Py3, where I see missteps and hamstrung APIs as active disincentivisation to my learning. Any half decent dev will just move on, because why would they put up with this? Did we not learn anything from PHP?