On 4 June 2016 at 09:12, Neil Schemenauer
As above (and we definitely won't revert it - it's one of the more appreciated changes reported by educators)
I'm not proposing to revert it. Sometimes I wonder if people actually read my proposal. I want a version of Python between 2.7.x and 3.x that allows it with a warning.
Who do you propose develops that version? Will you do so to help the next group of people in your situation? Even though there has been a formal pronouncement that Python 2.8 will not happen, someone could produce a fork, call it "transition Python" and add all the features you're asking for. Would people use it? I don't know. But the people who've asked for such a thing in the past have apparently never been sufficiently convinced it was a worthwhile effort to put their own time into it. People with large Python 2 codebases don't have to port. The lack of ongoing support for Python 2 from the core devs can be handled by other means (pay your distribution vendor for extended support, accept that Python 2 will freeze - it's not as if it's going to stop working - or maintain your own patches for Python 2.7, lots of options). Which, of course, may or may not suit your needs. The big part of the equation that's yet to become a major issue is libraries. At some point, library authors will start to face the decision of whether maintaining Python 2 support is worth it. Maybe only once Python 2 is no longer supported by the core devs, I don't know. But I don't see any major libraries that are *not* supporting Python 3 (even Twisted, probably the highest-profile example of a library that's had major problems porting, is getting Python 3 support). So the Python 2 community faces the prospect of what to do when libraries like pip, requests, numpy, ... stop supporting Python 2. (Equally, it would be a big issue if one of those major libraries announced that it would no longer support Python 3, but my instinct says that's unlikely). So it seems to me that for Python 2 users, the options are: 1. Stay where you are: Advantages - no porting costs, no risk of introducing new bugs in the port Disadvantages - platform will become less well supported (may cost money for support), key dependencies may also desupport Python 2, adding to the support question. 2. Port to Python 3: Advantages - Ongoing free support from the Python community, possibly better or cheaper vendor support Disadvantages - Porting cost, possibility of introducing new bugs during the port. 3. Your proposal of creating a transitional version: Advantages - ??? Porting costs are smaller? But there's the cost of developing the transitional version (or paying someone to do so). Unless you were hoping someone would do that for free, or you think that spreading the cost over a lot of people with the same needs will reduce the cost sufficiently... Disadvantages - At the moment, this option doesn't exist. So delays before you can even use it. And potential users (who might contribute help to the effort) may not be willing to wait. Any others? For me the killer there is "porting cost" which is why I say you don't have to port. The costs may easily outweigh the benefits. Maybe in your case, they did but nobody realised that in time. Maybe there's not enough impartial information on how to quantify the costs. I don't know. Paul