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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com