Thanks for doing this! I took a look at the arguments underlying the proposed switch to Python 3 and came to the conclusion that they did not meet the necessary threshold of effort to switch. Instead, I want to see every feature in Python 3 backported into 27. I don't think the unicode change can be accomodated, but 99% of the rest of the new features in 3 can.
Why I'm Making Python 2.8
161–170 of 392 posts
Re: Why I'm Making Python 2.8
#162Earlier quoted context omitted.
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…
I had this problem. 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…
It's unreasonable to say "merrily did something different, without telling anyone" when fixing the string implementation was a significant reason for creating backwards-incompatible Python3 in the first place.
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
Re: Why I'm Making Python 2.8
#163Earlier quoted context omitted.
> Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model. Except of course on operating systems where text I/O is done entirely in UTF-16. Say, Windows. Since Python strings have no fixed encoding, but choose "the…
> Since Python strings have no fixed encoding, but choose "the most efficient one" (heuristically) when decoding, they can cope better than a fixed UTF-8 encoding in these cases. That is wrong. Python can never pick the most efficient encoding unless you decode from latin1.
PEP 393
Re: Why I'm Making Python 2.8
#164> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. 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 writ…
> 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…
We have several large projects that are written in Python. Most of these aee production applications that are critical to what we do, and the others are libraries and tools for internal work. We haven't even started thinking about porting these to python3. We have so many other things to worry about (but fixes, new features, etc) that it's hard to justify the time investment to port these now. I can't imagine we're the only ones in this situation.
Re: Why I'm Making Python 2.8
#165> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. 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 writ…
> What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part.
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.
Re: Why I'm Making Python 2.8
#166Earlier quoted context omitted.
Python is trademarked by the Python Software foundation. IANAL but pretty sure that means he doesn't get to call it Python 2.8
Only if the PSF does something about it...
If they don't protect their trademark they open themselves up to what is essentially loss of the trademark in the US.
They could license it to Python 2.8 for free if they want to, though it seems unlikely.
Re: Why I'm Making Python 2.8
#167I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7.…
The effort to move from PHP v4 to v5 is comparable to the Python v2 to v3 move now. A lot of projects did not move to PHP5 for a long time. Lots of libraries had to be rewritten. The change brought a lot of subtle defects because programmers had unwittingly or knowingly relied on the by-value assignment of objects in PHP4.
The PHP Project did manage to allow people to write code that worked on both 4 and 5. At the same time, the project failed to get Unicode in. It's unclear how that will be possible without breaking a lot of programs. If PHP ever switches string handling like Python3 did now, it will be just as painful. Well, that's my prediction anyway, maybe they will figure something out. Just realize that their first try (PHP6) didn't fly at all.
Re: Why I'm Making Python 2.8
#168I never knew that despite Python 3 is called the future by PSF and has been around for a ling time, people still want to stick to Python 2. I mean it isn't the 2013 that libs aren't ported, most famous ones generally are ported. Don't know what the problem is.
Legacy python 2 code & an unwillingness to refactor it for python 3.
Re: Why I'm Making Python 2.8
#169Earlier quoted context omitted.
Are you implying Python3 is repressive?
"Port your old code or be left behind when we cut off 2.x line" is.
Please please please explain how that is inhibiting or restraining personal freedom. Or how it is inhibiting or preventing the expression or awareness of your thoughts or desires.
Re: Why I'm Making Python 2.8
#170I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7.…
>If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate. Massive breakage of backwards compatibility in a minor release is bad form. They absolutely did the right thing by naming it Python 3.0.
They could deprecate the breaking changes - for example Python 2.8 could make print statements needlessly more awkward to write but warn instead of error and Python 2.9/3.0 could make the changes permanent.
Rather than have this huge break maybe just take the time to move all of Python forward rather than us still 8 years after Python 3 leave us still talking about it.