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, Cameron Simpson wrote:
On Wed, 21 Apr 2021 at 09:01, Serhiy Storchaka <storchaka@gmail.com> 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 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. I frequently use str.format and str.format_map to produce strings from
On 21Apr2021 10:14, Paul Moore <p.f.moore@gmail.com> wrote: formats provided as configuration; in those methods I can't use arbitrary functions (injection, anyone?) For example:
fstags ls -o format-string-here ...
to produce a particular listing format.
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 "x".
Custom conversions would let me use this:
'{x} is {x!lc} in lowercase'
just by registering 'lc' as a conversion from my code. Chaining then per Serhiy's other suggestion would bring a fair amount of power.
Cheers, Cameron Simpson <cs@cskk.id.au> _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/7NWRKA... Code of Conduct: http://python.org/psf/codeofconduct/