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 <br...@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@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
