[Python-ideas] Gettext syntax (was Re: Allow "assigning" to ...)

[MRAB]

On 2015-02-13 00:01, Terry Reedy wrote:
> On 2/11/2015 10:33 PM, Terry Reedy wrote:
>
>> A possible solution would be to give 3.x str a __pos__ or __neg__
>> method, so +'python' or -'python' would mean the translation of 'python'
>> (the snake).  This would be even *less* intrusive and easier to write
>> than _('python').
>>
>> Since () has equal precedence with . while + and - are lower, we would
>> have the following equivalences for mixed expressions with '.':
>>
>> _(snake.format()) == -snake.format()  # format, then translate
>>                 # or -(snake.lower())
>> _(snake).format() == (-snake).format()  # translate, then format
>
> The core idea of this proposal is to add a single prefix symbol as an
> alternative to _(...).  Summarizing the alternate proposals:
>
> Zero Piraeus suggests that ~ (.__invert__ (normally bitwise)) would be
> better.  I agree.
>
> M.-A. Lemburg points out that neither of
>     label = +'I like' + +'Python'
>     label = -'I like' + -'Python'
> do not 'read well'.  I do not know how common such concatentions are,
> but I agree that they do not look good.
>
> He then suggests a new string prefix, such as i'Internationalized
> String'.  ('_' could also be used as a prefix.)  The compiler could map
> this to, for instance, sys.i18n('Internationalized String'), where initially
>     sys.i18n = lambda s: s
> The above code would then become
>     label = i'I like' + i'Python'  # or
>     label = _'I like' + _'Python'
> I like this even better except that it raises the issue of interaction
> with the existing r and b (and u) prefixes.
>
I think we can forget about any interaction with the b prefix. If
you're internationalising, you're using Unicode (aren't you?).

And as for the u prefix, it's really only used for compatibility with
Python 2, which won't have the i prefix anyway.

That leaves us with just i and ir.

> Ron Adam suggests a str._ property, leading to
>     label = 'I like'._ + 'Python'._
> I prefer 1 char to 2.  On the other hand, a 'suffix' makes a certain
> sense for indicating translation.  Current string prefixes affect the
> translation of literal to object. To properly process a string literal
> containing '\'s, for instance, both compilers and people need to know
> whether it is to be interpreted 'raw' or 'cooked'. Both also need to
> know whether to read it as text or bytes.  Translation is an
> afterthought, currently performed later.
>
>
> Barry Warsaw pointed out that existing tools can go thru a file, written
> in whatever language, and extract literal strings inside _(...).  For
> this, distinctive awkwardness is an advantage.  A new syntax would work
> better if there were a script to translate back to the old.
>