[Python-Dev] Trying to focus the whole bytes/str formatting discussion

[Brett Cannon]

I don't know about the rest of you but I feel like the discussion is
heading off the rails (if it hasn't already jumped the tracks). Let's try
to bring this back around to something actionable which people can focus
their energy on as the amount of developer time spent arguing could have
led to several coded-up solutions.

I see it as a practicality-beats-purity vs.
explicit-is-better-than-implicit. The PBP group want bytes.format() (just
assume I include interpolation support if you want that) to work as close
to a drop-in replacement for current str.format() use in Python 2 to ease
porting. The argument is that code looks cleaner and the amount of changes
in Python 2 code being ported to Python 3 is much smaller.

THE EIBTI group are willing to support PEP 460 but beyond that don't want
to have in Python itself anything for bytes.format() which takes in a
string and spits out bytes. It's bytes in->bytes out and not bytes & str
in->bytes out as the PBP group is after. The EIBTI group are arguing that
letting str into bytes.format() and then automatically be converted to
strict ASCII leads to conflating the text/bytes divide as well as being too
magical, e.g. what if you actually wanted UTF-16 for you number string
instead of ASCII; the EIBTI group **wants** to force people to make a
decision. They are also less concerned with making users update Python 2
code to handle this as it already needs to be updated for other Python 3
things anyway.

>From where I'm sitting, the EIBTI group and their PEP 460 proposal from
Antoine (and no longer Victor) are not controversial. Everyone seems to
agree that PEP 460 **at minimum** is acceptable and should happen for
Python 3.5. The people with the uphill battle and something to prove are
those arguing for str in->bytes out support in bytes.format(). The added
features that the PBP group want are the ones being argued over.

As the onus is on the PBP group to convince the EIBTI group (or Guido), I
think the PBP group should code up a solution that does what they want and
put it on PyPI to see what the community thinks. If the PBP group wants to
convince the EIBTI group that str in->bytes out for bytes.format() is
critical in getting a key group of users to start using Python 3 then I
think that needs to be demonstrated through real-world usage by some people.

If there is serious pickup of the solution from PyPI by projects then we
can discuss integrating it into Python 3.5. That gives at least **one
year** to come up with a solution which gets picked up by the community
(standard requirement for stdlib inclusion). At worst some projects use the
PyPI project and find it useful but it doesn't go into Python 3.5. At best
lots of people find it useful enough that we add it to Python 3.5. But
regardless, a PyPI project helps people **no matter what** the EIBTI group
thinks. That's more forward momentum than this conversation currently has.

This has split down philosophical lines and does not look to be tilting one
way or the other by simply using words. I think it has reached the point
that showing code is going to be the only way to tilt the favour towards
the PBP group at this point. Guido has not spoken up so either he is
ignoring it because he's busy, he doesn't care, or he's mulling things over
still. Assuming he doesn't speak up then it comes down to getting a clear
majority on the side of the PBP group and that is not going to happen the
way this discussion is going.

So, action items are:

* Get PEP 460 pronounced on **as is**
* A PyPI project containing PBP ideas and see if the community seizes on it
or not (benefit to people regardless)
* Do a separate PEP that builds on PEP 460 if people really want to
continue down that road at this time

Don't forget, we are talking about Python 3.5; we have not even hit Python
3.4rc1 yet so this level of arguing seems a bit premature and going nowhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140112/b0b3b919/attachment-0001.html>