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

[Guido van Rossum]

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)