[Python-Dev] PEP 460 reboot

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__/Py_buffer 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,

More information about the Python-Dev mailing list