[Python-Dev] Trying to focus the whole bytes/str formatting discussion (original) (raw)

Guido van Rossum guido at python.org
Mon Jan 13 01:56:35 CET 2014

Sorry, I started my own "PEP 460 reboot" thread -- I wrote that message before yours arrived, even if maybe I posted after you. I'm in the PBP camp myself for this. I won't pronounce on PEP 460 as-is. Please follow up in the other thread if you need clarifications.

On Sun, Jan 12, 2014 at 2:46 PM, Brett Cannon <brett at python.org> wrote:

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.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list