[Python-Dev] PEP-498: Literal String Formatting

[ISAAC J SCHWABACHER]

Now with syntax highlighting, if my email client cooperates:

code.putlines(f"""
static char {entry.doc_cname}[] = "{
    split_string_literal(escape_bytestring(docstr))}";

{ # nested!
f"""
#if CYTHON_COMPILING_IN_CPYTHON
    struct wrapperbase {entry.wrapperbase_cname};
#endif
""" if entry.is_special else ''}

{(lambda temp, argn: # my kingdom for a let!
f"""
for ({temp}=0; {temp}<PyTuple_GET_SIZE({argn}); {temp}++) {{
    PyObject *item = PyTuple_GET_ITEM({argn}, {temp});
}}""")(..., Naming.args_cname)}

{self.starstar_arg.entry.cname} =
    ({Naming.kwds_cname}) ? PyDict_Copy({Naming.kwds_cname})
                          : PyDict_New();

if (unlikely(!{self.starstar_arg.entry.cname})) return {self.error_value()};
""")

Better?

ijs


Top-posted from Microsoft Outlook Web App; may its designers be consigned for eternity to that circle of hell in which their dog food is consumed.

________________________________________
From: Python-Dev <python-dev-bounces+ischwabacher=wisc.edu at python.org> on behalf of Stefan Behnel <stefan_ml at behnel.de>
Sent: Sunday, August 9, 2015 04:53
To: python-dev at python.org
Subject: Re: [Python-Dev] PEP-498: Literal String Formatting

Stefan Behnel schrieb am 09.08.2015 um 10:06:
> Eric V. Smith schrieb am 08.08.2015 um 03:39:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer string format" thread. I'm open to a better title than
>> "Literal String Formatting".
>>
>> I need to add some text to the discussion section, but I think it's in
>> reasonable shape. I have a fully working implementation that I'll get
>> around to posting somewhere this weekend.
>>
>> >>> def how_awesome(): return 'very'
>> ...
>> >>> f'f-strings are {how_awesome()} awesome!'
>> 'f-strings are very awesome!'
>>
>> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
> [copying my comment from python-ideas here]
>
> How common is this use case, 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.

Thinking about this some more, the "almost all" is actually wrong. This
only applies to one kind of application that I'm working on. In fact,
"almost all" of the string formatting that I use is not in those
applications but in Cython's code generator. And there's a *lot* of string
formatting in there, even though we use real templating for bigger things
already.

However, looking through the code, I cannot see this proposal being of much
help for that use case either. Many of the values that get formatted into
the strings use some kind of non-trivial expression (function calls, object
attributes, also local variables, sometimes variables with lengthy names)
that is best written out in actual code. Here are some real example snippets:

    code.putln(
        'static char %s[] = "%s";' % (
            entry.doc_cname,
            split_string_literal(escape_byte_string(docstr))))

    if entry.is_special:
        code.putln('#if CYTHON_COMPILING_IN_CPYTHON')
        code.putln(
            "struct wrapperbase %s;" % entry.wrapperbase_cname)
        code.putln('#endif')

    temp = ...
    code.putln("for (%s=0; %s < PyTuple_GET_SIZE(%s); %s++) {" % (
        temp, temp, Naming.args_cname, temp))
    code.putln("PyObject* item = PyTuple_GET_ITEM(%s, %s);" % (
        Naming.args_cname, temp))

    code.put("%s = (%s) ? PyDict_Copy(%s) : PyDict_New(); " % (
            self.starstar_arg.entry.cname,
            Naming.kwds_cname,
            Naming.kwds_cname))
    code.putln("if (unlikely(!%s)) return %s;" % (
            self.starstar_arg.entry.cname, self.error_value()))

We use %-formatting for historical reasons (that's all there was 15 years
ago), but I wouldn't switch to .format() because there is nothing to win
here. The "%s" etc. place holders are *very* short and do not get in the
way (as "{}" would in C code templates). Named formatting would require a
lot more space in the templates, so positional, unnamed formatting helps
readability a lot. And the value expressions used for the interpolation
tend to be expressions rather than simple variables, so keeping those
outside of the formatting strings simplifies both editing and reading.

That's the third major real-world use case for string formatting now where
this proposal doesn't help. The niche is getting smaller.

Stefan


_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/ischwabacher%40wisc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150811/8aba7e43/attachment-0001.html>