On 25 February 2014 17:43, Stuart Bishop <stu...@stuartbishop.net> wrote: > On 23 February 2014 08:56, Ethan Furman <et...@stoneleaf.us> wrote: > >> ``%a`` will call :func:``ascii()`` on the interpolated value's >> :func:``repr()``. >> This is intended as a debugging aid, rather than something that should be >> used >> in production. Non-ascii values will be encoded to either ``\xnn`` or >> ``\unnnn`` >> representation. > > So we use %a for exactly the same purposes that we used to use %r. > >> Unsupported codes >> ----------------- >> >> ``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not >> supported. > > But you propose changing the code. > > I think there would have been a lot less discussion if you just > defined %r to do what you propose for %a, as everything would work as > people expected.
No, it wouldn't. [Python 3] >>> "%r" % "\xe9" "'é'" >>> "%a" % "\xe9" "'\\xe9'" %r is being disallowed in PEP 461 because it doesn't guarantee ASCII compatibility in Python 3 the way it did in Python 2. That's not up for discussion, as having %r behave like %a in binary interpolation but not in text interpolation would be far too confusing. However, %a *already* guarantees ASCII compatible output for text interpolation (by escaping everything below 0x20 or above 0x7F, the same way %r did in Python 2), so some of us think %a *should* be allowed for consistency with text interpolation, both because there's no compelling reason to disallow it and because it's the obvious way to interpolate representations of arbitrary objects into binary formats that contain ASCII compatible segments. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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