

PEP 461 Accepted: Adding % formatting to bytes and bytearray - adamnemecek
https://mail.python.org/pipermail/python-dev/2014-March/133621.html

======
deckiedan
In an interesting parallel universe, Python 3.0 was released with only two
changes, namely the UTF-8 system, and no "old-school" classes. Nothing else
was added, and no features were removed. It was a huge success, and the whole
community switched over in about a year. Each new release added features, but
there was much less wailing, sarcastic blog posts and gnashing of teeth.

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.

~~~
masklinn
> namely the UTF-8 system

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.

~~~
ygra
> inability to play fast and lose with the definition of "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).

~~~
masklinn
> If that wasn't intentional it's a very fitting typo.

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.

[1] [http://lucumr.pocoo.org/2014/1/5/unicode-
in-2-and-3/](http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/)

------
kzrdude
Wait -- wasn't % formatting deprecated long ago in favour of the .format()
method?

~~~
njharman
Some people thought % formatting sucked and made .format(). It was then
discovered that some not insignificant number of people found .format() a
complex abomination and so deprecation plans were nixed.

~~~
beaumartinez
Interesting—do you have any links to back this up?

~~~
njharman
Nope, it is my opinion.

------
fnl
And so yet another reason for "not migrating" to 3.x is off the table...

------
jordigh
Yes! This will finally make it possible to migrate Mercurial (which the Python
devs themself use [http://hg.python.org/](http://hg.python.org/) ) to Python
3!

In fact, I'm pretty sure hg was their biggest reason to accept this PEP.

------
klibertp
After seeing the title I thought about something like Erlang's pattern
matching on binaries, which is absolutely amazing. Turn's out it's just one
way support for generating byte strings, but it's still good :)

------
TorKlingberg
Nice! I had this problem when I was using Python to control some lab hardware
over telnet. I tried using Python 3 at first, but it was just so much easier
in Python 2 with string formatting.

------
captainmuon
Python 3, Gnome 3, Windows 8 (could that be Post-XP Windows No. 3?). Lets
break the world, introduce new features that sound good on paper but break the
work(flow) of many people. Then slowly backpedal and over time reintroduce all
the important tiny things from the previous release... I wonder what the
reason for this pattern is. Guess "break the world" never works as well as one
wishes.

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, ...)

~~~
baq
right now i'm happily coding in Python 3.4 on Windows 8. it can be done now
and it's mostly painless.

~~~
captainmuon
Sure, so am I...privately. But all my serious work stuff is in Python 2, and
no one is going to pay me to update it, so I cant't. Now I guess, if in a year
or so Python 3 will have gained back a few more features of Python 2, porting
my stuff will finally be easy enough.

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.

