On 24 Feb 2014 07:39, "Antoine Pitrou" <solip...@pitrou.net> wrote: > > On Sun, 23 Feb 2014 12:42:59 -0800 > Ethan Furman <et...@stoneleaf.us> wrote: > > On 02/23/2014 03:33 AM, Antoine Pitrou wrote: > > > On Sat, 22 Feb 2014 17:56:50 -0800 > > > 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. > > > > > > Why is "%a" here? I don't remember: was this discussed before? > > > "Intended as a debugging aid" sounds like a weak justification to me. > > > > https://mail.python.org/pipermail/python-dev/2014-January/131808.html > > > > The idea being if we offer %a, folks won't be tempted to abuse __bytes__. > > Which folks are we talking about? This sounds gratuitous.
It's a harm containment tactic, based on the assumption people *will* want to include the output of ascii() in binary protocols containing ASCII segments, regardless of whether or not we consider their reasons for doing so to be particularly good. If %a exists, then the path of least resistance to doing this only affects the format string, and it can handle arbitrary types (except bytes under -b and -bb). By contrast, if %a doesn't exist, then it becomes more attractive to use %s in the format string and define an ASCII assuming __bytes__ implementation on a custom type. That latter scenario is substantially more problematic, since __bytes__ implementations assuming ASCII compatibility is categorically wrong, while embedding an ASCII representation in a binary protocol that includes ASCII compatible segments is merely a bit strange. Cheers, Nick. > > Also, I don't understand what debugging is supposed to be in the > context of bytes formatting. You print debugging output to a text > stream, not a bytes stream. And you certainly *don't* print debugging > output into a wire protocol. > > Regards > > Antoine. > > > _______________________________________________ > 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/ncoghlan%40gmail.com
_______________________________________________ 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
