A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2015-August/141181.html below:

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

[Python-Dev] PEP-498: Literal String Formatting [Python-Dev] PEP-498: Literal String FormattingEric V. Smith eric at trueblade.com
Mon Aug 10 20:49:05 CEST 2015
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.

Eric.


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4