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

Guido van Rossum guido at python.org
Mon Jan 13 21:09:23 CET 2014

On Mon, Jan 13, 2014 at 11:57 AM, Barry Warsaw <barry at python.org> wrote:

On Jan 13, 2014, at 02:13 PM, Donald Stufft wrote:

On Jan 13, 2014, at 1:58 PM, Guido van Rossum <guido at python.org> wrote:

I hear the objections against b'%s' % 'x' returning b"'x'" loud and clear, and if the noise about that sub-issue is preventing folks from seeing the absurdity in PEP 460, we can talk about a compromise, e.g. use %b which would require its argument to be bytes. Those bytes should still probably be ASCII-ish, but there's no way to test that. That's fine with me and should be fine to Nick as well -- PEP 460 doesn't check that your encodings match (how could it? :-), nor does plain string concatenation using +.

I think disallowing %s is the right thing to do, but I definitely think numbers and %b should be allowed.

I guess I agree. The behavior of b'%s' % 'x' returning b"'x'" is almost always useless at best. (I would have thought maybe %a for ascii() but don't care that strongly.)

Yeah, the %s behavior with a string argument was a messy attempt at compromise. I was hoping to mimick a common use of %s in Python 2, where it can be used with either an 8-bit string or a number as argument, acting like %b in the former case and like %d in the latter case. Not having %s at all in Python 3 means that porting requires more thinking (== more opportunity for mistakes when you're converting in bulk) and there's no easy way to write code that works in Python 2 and 3.

If we have %b for strictly interpolating bytes, I'm fine with adding %a for calling ascii() on the argument and then interpolating the result after ASCII-encoding it.

If somehow (unlikely though it seems) we end up keeping %s (e.g. strictly to ease porting), we could also keep %r as an alias for %a.

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

More information about the Python-Dev mailing list