On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka <storch...@gmail.com> wrote:
>
> Currently format strings (and f-string expressions) support three
> conversions: !s -- str, !r -- repr and !a for ascii.
>
> I propose to add support of additional conversions: for int, float and
> operator.index. It will help to convert automatically printf-like format
> strings to f-string expressions: %d, %i, %u -- use int, %f -- use float,
> %o, %x -- use operator.index.
I've never had any particular need for these, but I can see that they
would be logical additions.
> For float the conversion letter is obvious -- !f. But I am not sure for
> what !i should be used, for int or operator.index. If make it
> operator.index, then !d perhaps should be used for int. If make it int,
> then !I perhaps should be used for operator.index. Or vice verse?
I don't have a particularly strong opinion here, other than to say I'm
not sure I like the upper case "I". It looks far too much like a lower
case "L" in the font I'm using here, which makes me think of C's
"long", so it's easy to confuse. So of the two options, I prefer !f,
!d, !i over !f, !i, !I.
> Also I propose to support applying multiple conversions for the same
> item. It is common when you output a path or URL object as quoted string
> with all escaping, because in general it can contain special or
> non-printable characters. Currently I write f"path = {repr(str(path))}"
> or f"path = {str(path)!r}", but want to write f"path = {path!s!r}".
This, I would definitely use. I use f"path = {str(path)!r}" quite a
lot, and being able to reduce that to f"{path=!s!r}" would be really
convenient for debugging (even if it does look a bit like a string of
magic characters at first glance).
> Do we need support of more standard conversions? Do we want to support
> custom conversions (registered globally as encodings and error
> handlers). re.escape, html.escape and shlex.quote could be very useful
> in some applications.
That appeals to me just because I like generic features in general,
but I'm not sure there are sufficient benefits to justify the
complexity for what would basically be a small convenience over
calling the function directly.
Paul
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PWVCP2IHS22DK6FWEMBTHIGQPLAJBXAX/
Code of Conduct: http://python.org/psf/codeofconduct/
