PEP 461 Accepted: Adding % formatting to bytes and bytearray
mail.python.org
mail.python.org
Due to quantum, and lots of sci-fi nonsense, that universe is slowly distorting this one until eventually python3 reaches it's state of historical 'rightness'.
In a few years time, all of time and space itself will only reflect this new reality, except for a small number of blogposts about how "Python3k will never take off" which will sit silent and forgottern, a mere curiosity in the endless halls of cyberspace.
What are you talking about here? Is it the FSR introduced in 3.3, or the split between unicode and byte strings? Because if the latter
> and the whole community switched over in about a year.
must have been written under influence, the unicode/bytes semantics split and inability to play fast and loose with the definition of "string" in P3 is by far the biggest difficulty when switching between P2 and P3[0].
And that split and the backwards incompatibility it generated is pretty much the reason why the core team felt adding further non-BC features was OK: there was no way usual non-trivial P2 code would work on P3 in the first place (especially since this was in the 2.6 release cycle, most of the backports were added later in 2.7), so they may as well clean up the language and stdlib while at it.
[0] and the reason why most libraries didn't work OOTB, and why some protocol — WSGI for instance — had to be rethought in-depth to try and understand what is and is not a string.
If that wasn't intentional it's a very fitting typo. In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs which tends to work somewhat until it breaks (similar to string handling in C/C++ when Unicode is encountered).
It wasn't[0], and though I agree I fixed it.
> In either case it describes perfectly why Python 3's distinction between text and data (or Unicode and byte strings) is much better than the Python 2 state of affairs
Yes, although it really annoys people who work at the boundary or in domains where the distinction is unclear or ill-defined (urls, HTTP headers, environment variables, …). Which is probably why e.g. Armin Ronacher has so many issues with it[1]: the vast majority of his stuff (at least for the libraries he releases) operate across these boundaries.
[0] I actually spent a second wondering, and then I got it wrong anyway.
'explicit is better than implicit' - hah.
(Eg, one of my clients had code with "import *" inside of functions, which no longer worked with 2.x. This syntax error alone was enough to keep them on 1.5.4 for a long time, before finally committing time to make the change.)
I like the new import semantics a lot. It removed all ambiguity from the old one.
> As noted above, ``%s`` is being included solely to help ease migration from, and/or have a single code base with, Python 2.
%s was never deprecated. str.format is said to be preferred, and maybe one day it will completely replace %s. Heaven knows if that'll even happen in 4.0, it's a bigger switch than 3.x's print() and unicode changes combined.
In fact, I'm pretty sure hg was their biggest reason to accept this PEP.
I think I'll wait maximally one more release cycle and try Gnome again, and finally start porting my stuff to Python 3. Windows XP+3.1 (=8.1) is also pretty usable again. Just waiting for the integration of Metro and Desktop to be a bit closer (e.g. integrate Aero snap and Metro snapping, have one common taskbar, allow me to have the Metro PDF viewer next to a "fullscreen" sublime text, allow Desktop apps to "go Metro Fullscreen" a bit like the fullscreen in OSX Lion, ...)
I have to add though that maybe my use case is a bit unusual. I'm not a "professional developer", but a scientist. In our case the developers of our programs are the users, and everybody has to be able to edit them. So there is a lot of inertia to change. Also we do a lot of "crazy" things, like custom C modules, mixing Python/C(++), using Python as a description language for batch jobs, and so on. Previous updates were not trivial, but possible. But somehow we never managed to make the jump to Version 3 of anything. Hell, we just started to switch from SVN to git...
What I'm trying to say is, it's kind of sad that there are all these cool "new" technologies and paradigms and we seem to be unable to pass the threshold to them. I see people around me alienated by Windows 8, Gnome, and so on, so instead of updating they stick with their old setup or switch to Mac, not because it is superior, but because it is the most conservative option. For the same reason we stick with old versions of Python, GCC, Red Hat, and so on. The only machines I can currently do my work on are my work PC with like 5 year old CentOS on it, or my Hackintosh at home, because stuff won't run on newer (non-OSX) systems.
I guess I'm just a bit angry that I always suffer from these "Break the world, do the right thing, let's be bold" kind of upgrades. It's great for people living on the edge, who can pick themselves what they want to use. Other people have to wait for the goodness to trickle down, and that has been taking way to long in case of Python 3 for me.