But IIUC once a conversion was added, it could not be removed without
breaking backward compatibility. So I think we should be cautious about
building what is in effect a Domain Specific Language and take care to
get it (as) right (as possible) first time.
Rob Cliffe
On 21/04/2021 22:44, Cam
On 21Apr2021 10:14, Paul Moore wrote:
>On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka wrote:
>> 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 b
Hah, should have put more effort in my research then. And so recent too.
Well, it is not something easy to search for.
I read the other thread, and I am inclined to agree with Paul. Whether
or not the execution enters the function (as in: new entry in the call
stack) during setup is really an i
On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka 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 au
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
