[Python-ideas] Briefer string format

[Andrew Barnert]

On Aug 9, 2015, at 01:00, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 
> Mike Miller schrieb am 09.08.2015 um 02:48:
>>> On 08/08/2015 09:49 AM, Stefan Behnel wrote:
>>> Mike Miller schrieb am 20.07.2015 um 01:35:
>>>>     csstext += '{nl}{key}{space}{{{nl}'.format(**locals())
>>>> 
>>>> This looks a bit better if you ignore the right half, but it is longer
>>>> and not
>>>> 
>>>>    csstext += '{nl}{key}{space}{{{nl}'.format(nl=nl, key=key, ...  # uggh
>>>>    csstext += '{}{}{}{{{}'.format(nl, key, space, nl)
>>> 
>>> Is this an actual use case that people *commonly* run into? I understand
>>> that the implicit name lookups here are safe and all that, but I cannot
>>> recall ever actually using locals() for string formatting.
>> 
>> There are several ways to accomplish that line.  If you look below it there
>> two alternatives, that are suboptimal as well.
>> 
>>> The above looks magical to me. It's completely unclear that string
>>> ...
>>> I'd prefer not seeing a "cool feature" added just "because it's cool". If
>>> it additionally is magic, it's usually not a good idea.
>> 
>> Direct string interpolation is a widely desired feature, something the
>> neckbeards of old, hipsters, and now suits have all agreed on.
> 
> But how common is it, really? Almost all of the string formatting that I've
> used lately is either for logging (no help from this proposal here) or
> requires some kind of translation/i18n *before* the formatting, which is
> not helped by this proposal either.

There's also text-based protocols, file formats, etc. I use string formatting quite a bit for those, and this proposal would help there.

Also, do you really never need formatting in log messages? Do you only use highly structured log formats? I'm always debug-logging things like "restored position {}-{}x{}-{} not in current desktop bounds {}x{}" or "file '{}' didn't exist, creating" and so on, and this proposal would help there as well.

But you're right that i18n is a bigger problem than it appears. I went back through some of my Swift code, and some of the blog posts others have written about how nifty string interpolation is, and I remembered something really obvious that I'd forgotten:

Most user-interface strings in Cocoa[Touch] apps are in the interface-builder objects, or at least explicitly in strings files, not in the source code. (I don't know if this is similar for C# 8's similar feature, since I haven't done much C# since .NET was still called .NET, but I wouldn't be surprised.) So you don't have to i18n source-code strings very often. But when you do, you have to revert to the clunky ObjC way of creating an NSLocalizedString with %@ placeholders and and calling stringWithFormat: on it. In Python, user-interface strings are very often in the source code, so you'd have to revert to the 3.5 style all the time. Which isn't nearly as clunky as the ObjC style, but still...

Now I have to go back and reread Nick's posts to see if his translated-and-interpolated string protocol makes sense and would be easy to use for at least GNU gettext and Cocoa (even without his quasi-associated semi-proposal for sort-of-macros), because without that, I'm no longer sure this is a good idea. If the feature helps tremendously for non-i18n user interface strings, but then you have to throw it away to i18n your code, that could just discourage people from writing programs that work outside the US. (I suspect Nick and others already made this argument, and better, so apologies if I'm being slow here.)