On 4/23/2021 5:22 AM, Stephen J. Turnbull wrote:
But we could change int.__format__ to allow 's' as a format code[1],
automagically calling str(), just as 'efg' are allowed and
automagically call float().
...
[1] I recognize this may imply many changes, since some (all?) of the
builtin types s
On 23Apr2021 18:25, Stephen J. Turnbull
wrote:
>Cameron Simpson writes:
> > I would _frequently_ like to be able to provide custom
> > conversions. At present I'm using elaborate hacks based on
> > __getattr__ etc to recognise things like this:
> >
> > '{x} is {x_lc} in lowercase'
> >
> > whe
On Fri, Apr 23, 2021 at 7:26 PM Stephen J. Turnbull
wrote:
>
> Cameron Simpson writes:
>
> > I would _frequently_ like to be able to provide custom
> > conversions. At present I'm using elaborate hacks based on
> > __getattr__ etc to recognise things like this:
> >
> > '{x} is {x_lc} in l
On Fri, Apr 23, 2021 at 7:24 PM Stephen J. Turnbull
wrote:
>
> Serhiy Storchaka writes:
>
> > Currently format strings (and f-string expressions) support three
> > conversions: !s -- str, !r -- repr and !a for ascii.
>
> It's not clear to me what these are good for, to be honest. Why not
> just
Cameron Simpson writes:
> I would _frequently_ like to be able to provide custom
> conversions. At present I'm using elaborate hacks based on
> __getattr__ etc to recognise things like this:
>
> '{x} is {x_lc} in lowercase'
>
> where the _lc suffix is caught and a value computed from
Serhiy Storchaka writes:
> Currently format strings (and f-string expressions) support three
> conversions: !s -- str, !r -- repr and !a for ascii.
It's not clear to me what these are good for, to be honest. Why not
just have s, r, and a format codes? The !conversions don't compose
with forma