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

Carl Meyer carl at oddbird.net
Mon Aug 10 21:04:40 CEST 2015


On 08/10/2015 02:49 PM, Eric V. Smith wrote:
> On 08/10/2015 02:44 PM, Yury Selivanov wrote:
>>
>>
>> On 2015-08-10 2:37 PM, Eric V. Smith wrote:
>>>> Besides, any expression you have to calculate can go in a local that
>>>> will get
>>>>> interpolated.  The same goes for any !r or other formatting
>>>> modifiers.  In an
>>>>> i18n context, you want to stick to the simplest possible substitution
>>>>> placeholders.
>>> This is why I think PEP-498 isn't the solution for i18n. I'd really like
>>> to be able to say, in a debugging context:
>>>
>>> print('a:{self.a} b:{self.b} c:{self.c} d:{self.d}')
>>>
>>> without having to create locals to hold these 4 values.
>>
>> Why can't we restrict expressions in f-strings to
>> attribute/item getters?
>>
>> I.e. allow f'{foo.bar.baz}' and f'{self.foo["bar"]}' but
>> disallow f'{foo.bar(baz=something)}'
> 
> It's possible. But my point is that Barry doesn't even want
> attribute/item getters for an i18n solution, and I'm not willing to
> restrict it that much.

I don't think attribute access and item access are on the same level
here. In terms of readability of the resulting string literal, it would
be reasonable to allow attribute access but disallow item access. And I
think attribute access is reasonable to allow in the context of an i18n
solution as well (but item access is not). Item access is much harder to
read and easier for translators to mess up because of all the extra
punctuation (and the not-obvious-to-a-non-programmer distinction between
a literal or variable key).

There's also the solution used by the Django and Jinja templating
languages, where dot-notation can mean either attribute access
(preferentially) or item access with literal key (as fallback). That
manages to achieve both a high level of readability of the
literal/template, and a high level of flexibility for the context
provider (who may find it easier to provide a dictionary than an
object), but may fail the "too different from Python" test.

Carl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150810/cc19d809/attachment.sig>


More information about the Python-Dev mailing list