Author arcivanov
Recipients arcivanov
Date 2018-02-26.10:19:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1519640359.67.0.467229070634.issue32954@psf.upfronthosting.co.za>
In-reply-to
Content
I'd like to start a discussion on/gauge interest for introducing an enhancement to PEP-498 in a form of delayed/lazy/lambda f-string.

The proposed change is, conceptually, minor and would not differ from PEP-498 syntactically at all except for string prefix.

E.g. 

     extra = f'{extra},waiters:{len(self._waiters)}'

becomes

     extra = fl'{extra},waiters:{len(self._waiters)}'

The proposal would produce a lambda-like object x('format'), where x.__str__() == f'format'.

This should come extremely useful in all cases where delayed or conditional string formatting and concatenation are desired, such as in cases of logging.

As an example, currently, the 

    logger.debug("Format %s string", value) 

cannot be used with an f-string as follows 

    logger.debug(f"Format {value} string") 

without an unconditional evaluation of all parameters due to current compilation prior to logging checking whether it's even enabled for debug:

>>> b = 1
>>> def a(x):
...     return f"Foo {x} bar {b}"
... 
>>> dis.dis(a)
  2           0 LOAD_CONST               1 ('Foo ')
              2 LOAD_FAST                0 (x)
              4 FORMAT_VALUE             0
              6 LOAD_CONST               2 (' bar ')
              8 LOAD_GLOBAL              0 (b)
             10 FORMAT_VALUE             0
             12 BUILD_STRING             4
             14 RETURN_VALUE

Additional great optimizations may be rendered by introducing an a fl-string is a case where

    foo = "foo"
    s1 = fl"S1 value ${foo}"
    s2 = fl"S2 value of ${s1}"
    print(s2)

may produce only one BUILD_STRING instruction, potentially dramatically increasing performance in heavy string-concat based applications. 

Even when a compiler will not be able to statically prove that a particular value is in fact an fl-string, an interpreter-level check or a JIT-based Python implementation may be able to optimize such concats ad-nauseam (with trap-based deopt), allowing to collapse an extremely long chains of formats into a single BUILD_STRING op without any intermediary string allocation/concatenation (very useful in cases such as web servers, templating engines etc).

I'll be happy to produce patches against 3.7/3.8 for this if a general concept is found useful/desirable by the community.
History
Date User Action Args
2018-02-26 10:19:19arcivanovsetrecipients: + arcivanov
2018-02-26 10:19:19arcivanovsetmessageid: <1519640359.67.0.467229070634.issue32954@psf.upfronthosting.co.za>
2018-02-26 10:19:19arcivanovlinkissue32954 messages
2018-02-26 10:19:19arcivanovcreate