On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka <storchaka@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