[Python-Dev] PEP 460 reboot (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Tue Jan 14 18:57:05 CET 2014


On January 14, 2014 at 12:47:35 PM, Brett Cannon (brett at python.org) wrote:

On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote: > Brett, > > > I like your proposal. There is one idea I have that could, > perhaps, improve it: > > > 1. “%s" and “{}” will continue to work for bytes and bytearray in > the following fashion: > > - check if bytes/Pybuffer supported. > - if it is, check that the bytes are strictly in the printable > ASCII-subset (a-z, A-Z, 0-9 + special symbols like ! etc). > Throw an error if the check fails. If not - concatenate. > - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result.

> > This way most of the use cases of python2 will be covered without > touching the code. So: > See, I'm fine with having people update their format strings to specify a format spec; it's minor and isn't totally useless as it expresses what they mean more explicitly (e.g. "I want this to be a int, I want this to be a float, and I want this to be an ASCII string" using d, f, and s, respectively). I want people to have to make a conscious decision to fall back on an ASCII encoding. What you are suggesting is for people have to make a conscious decision not to encode to ASCII implicitly which is what I'm trying to avoid with this proposal. My goal is to make it easy to work with ASCII but as an explicit choice to, not by default.

I understand.  But OTOH, this whole discussion started because of  the lack of convenience to work with bytes in py3, plus it’s hard to maintain same codebase.  Updating the code to include new ‘%b’ operators won’t help them.

My proposal is based on the assumption, that most of the string formatting people usually use in python2 on ‘str’ (not ‘unicode’) is used for ascii. That’s the implicit convenience of using bytes that everybody is looking for in py3. It allows having single codebase, and provides the necessary safety.

Anyways, my 2 cents.

Thank you, Yury



More information about the Python-Dev mailing list