[Python-ideas] Gettext syntax (was Re: Allow "assigning" to ...)
MRAB
python at mrabarnett.plus.com
Fri Feb 13 02:55:50 CET 2015
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.
>
More information about the Python-ideas
mailing list