The distinction between %()s and %()r, recently introduced, has been useful. But with str() and repr(), only one of those is really necessary. But it gave the impression that Python trend is pushing for % to get stronger. The proposal of using $ as yet another formatting avenue makes it weaker.

Language evolution doesn't always go into a straight line.

...

Less clutter. Compare

...

"My name is $name, I live in $country"

...

to

...

"My name is ${name}, I live in ${country}"

...

The {} add nothing but noise. We're copying this from the shell.

Noise decreases legibility. So, maybe the PEP should not say that ${name} is to be preferred over $name? Or else, it should explain why.

I agree that I see no reason to prefer ${name} (except when followed by another word character of course). --Guido van Rossum (home page: http://www.python.org/~guido/)

[Guido van Rossum]

I quite like the positional % substitution. I think %(...)s was a mistake -- what we really wanted was ${...}.

What is the advantage of curly braces over parens in this context? +1 on the allvars() suggestion also. -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python software development." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------

...

...

...

...

"GvR" == Guido van Rossum writes:

GvR> Apart from Make, most $ substituters use ${...}, not $(...). GNU Make allows either braces or parentheses; there's no difference between the two. So it's a pretty strong precedent in lots of Unix tools. GNU Make also uses the $$ escape. -Barry

[Guido van Rossum]

...

...

I quite like the positional % substitution. I think %(...)s was a mistake -- what we really wanted was ${...}.

What is the advantage of curly braces over parens in this context?

Apart from Make, most $ substituters use ${...}, not $(...).

I guess what I was really wondering is whether that advantage clearly outways some of the possible disadvantages. I'm not a fan of curly braces and I'll be sad to see more of them in Python. There's something refreshing about only having curly braces for dictionaries and parens everywhere else. And since the exisiting string substitution uses parens why shouldn't the new? It won't surprise me that you've already considered all this and are fine with using curly braces here, but I just had to ask before it is a done deal. (And I promise I won't go on a boolean crusade and predict that curly braces will appear everywhere to the demise of the language. <wink>) -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python software development." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------

[Guido van Rossum]

...

I'm not a fan of curly braces and I'll be sad to see more of them in Python.

This seems more emotional than anything else.

Definitely. And habit. Since I program mostly in Python I'm used to {} meaning dictionary and I'm used to typing parens everywhere else. Others who are used to ${} for string substitution in other contexts will be happy that you copied that syntax. I'm just trying to see if there is anything more substantial involved. Sounds like there isn't. And that's fine. I'll adapt. :-) -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python software development." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------

Patrick K. O'Brien wrote:

[Guido van Rossum]

...

I quite like the positional % substitution. I think %(...)s was a mistake -- what we really wanted was ${...}.

What is the advantage of curly braces over parens in this context?

It unambiguously spells that there is no format suffix char.

+1 on the allvars() suggestion also.

me too. -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Guido van Rossum wrote:

Christian,

you seem to be contradicting yourself. First:

[someone]

...

...

+1 on the allvars() suggestion also.

[Christian]

...

me too.

and later:

[Christian]

...

The following statements are ordered by increasing hate. 1 - I do hate the idea of introducing a "$" sign at all. 2 - giving "$" special meaning in strings via a module 3 - doing it as a builtin function 4 - allowing it to address local/global variables

Doesn't 4 contradict your +1 on allvars()?

By no means. allvars() is something like locals() or globals(), just an explicit way to produce a dictionary of variables. What I want to preserve is the distinction between arbitrary "%(name)s" or maybe "${name}" names and my local variables. Using locals() or allvars(), I can decide to *feed* the formatting expression with variable names. But the implementation of .sub() should not know anything about variables, the same way as % doesn't know about variables. Formatting is "by value", IMHO. Furthermore I'd like to thank Alex for his opinions, additions and adjustments to my post. I have to say that I always *am* emotional with such stuff, although I'm trying hard not to. But he hits the nail's head more than I. cheers - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Barry A. Warsaw:

def whereBorn(name): country = countryOfOrigin(name) return _('$name was born in $country') ... The feature would be useless to me if I had to pass some explicit dictionary into the _() method. It makes writing i18n code extremely tedious.

I think you are overstating the problem here. The explicit bindings are a small increase over your current code as you are already creating an extra variable just to use the automatic binding. With explicit bindings: def whereBorn(name): return _('$name was born in $country', name=name, country=countryOfOrigin(name)) The protection provided is not just against untrustworthy translaters but also allows checking the initial language code. You can ensure all the interpolations are provided with values and all the provided values are used. It avoids exposing implementation details such as the names of local variables and can ensure that a more meaningful identifier in the local context of the string is available to the translator. For example, I may have some code that processes a command line argument which has multiple uses on different execution paths: _('$moduleName already exists', moduleName = arg) _('$searchString can not be found', searchString = arg) Not making bindings explicit may mean that translators use other variables available at the translation point leading to unexpected failures when internal details are changed. Neil

[Barry A. Warsaw]

"NH" == Neil Hodgson

Another i18n approach altogether uses explicit message ids instead of using the source string as the implicit message id, but that has a whole 'nuther set of issues.

The `catgets' approach, by opposition to the `gettext' approach. I've seen some people having religious feelings in either direction. Roughly said, `catgets' is faster, as you directly index the translation string without having to hash the original string first. It is also easier to translate single words or strings offering little translation context, as English ambiguities are resolved by using different message ids for the same text fragment. On the other hand, `gettext' can be made nearly as fast as `catgets', only _if_ we use efficient hashing combined with proper caching. But the real advantage of `gettext' is that internationalised sources are more legible and easier to maintain, since the original string is shown in clear exactly where it is meant to be used. A problem with both is that implementations bundled in various systems are often weak of bugged, provided they exist of course. Portability is notoriously difficult. Linux and GNU `gettext' rate rather nicely. But nothing is perfect.

[...] you tend to get paranoid about changing /any/ source string, say to remove a comma, adjust whitespace, or fix a preposition. Any change means a dozen language teams have a new message they must translate (unless you can mechanically fix them for them).

This is why the responsibilities between maintainers and programmers ought to be well split. If the maintainer feels responsible for the work that is induced on the translation teams by string changes, comfort is lost. The maintainer should do its work in all freedom, and the problem of later reflecting tiny editorial changes into PO `msgstr' fully pertains to translators, with the possible help of automatic tools. Translators should be prepared to such changes. If the split of responsibilities is not fully understood and accepted, internationalisation becomes much heavier, in practice, than it has to be.

>> The feature would be useless to me if I had to pass some explicit >> dictionary into the _() method. It makes writing i18n code >> extremely tedious.

NH> I think you are overstating the problem here.

Trust me, I'm not. [...] being forced to pass in the explicit bindings is a big burden in terms of maintainability and readability.

NH> Not making bindings explicit may mean that translators use NH> other variables available at the translation point leading to NH> unexpected failures when internal details are changed.

I18n'ing a program means you have to worry about a lot more things. [...]

Internationalisation should not add a significant burden on the programmer. I mean, if there is something cumbersome in the internationalisation of a string, then there is something cumbersome in that string outside any internationalisation context. If internationalisation really adds a significant burden, this is a signal that internationalisation has not been implemented well enough in the underlying language, or else, that it is not getting used correctly. I really think that internationalising of strings should be designed so it is a light activity and negligible burden for the maintainer. (And of course, translators should also get help in form of proper files and tools.) -- François Pinard http://www.iro.umontreal.ca/~pinard

I'm pretty negative on string interpolation, I don't see it as that useful or %()s as that bad. But obviously, many others do feel there is a problem. I don't like the schism that $ vs. % would create. Nor do I like many other proposals. So here is yet another proposal: * Add new builtin function interp() or some other name: def interp(format, uselocals=True, useglobals=True, dict={}, **kw) * use % as the format character and allow optional () or {} around the name * if this is acceptable, {name:format_modifiers} could be added in the future Code would then look like this: >>> x = 5 >>> print interp('x = %x') x = 5 >>> print interp('x = %(x)') x = 5 >>> print interp('x = %{x}') x = 5 >>> print interp('y = %y') NameError: name 'y' is not defined >>> print interp('y = %y', dict={'y': 10}) y = 10 >>> print interp('y = %y', y=10) y = 10 This form: * eliminates any hint of $ * is similar to current % handling, but hopefully fixes the current deficiencies * allows locals and/or globals to be used * allows any dictionary/mapping to be used * allows keywords * is extensible to allow for formatting in the future * doesn't require much extra typing or thought Now I'm sure everyone will tell me how awful this is. :-) Neal PS I'm -0 on this proposal. And I dislike the name interp.

...

...

...

...

"FP" == François Pinard writes:

>> It may not be a significant burden, once the infrastructure is >> in place and a rhythm is established, but it is still not >> non-zero. FP> The Mailman effort has been especially courageous, as it ought FP> to address many problems on which we did not accumulate much FP> experience yet, but which are inescapable in the long run. FP> For example, I guess you had to take care of translating FP> external HTML templates, considering some input aspects, FP> allowing on-the-fly language selection, and of course, looking FP> into more prosaic non-message "locale" concerns. Thanks, I think it's been valuable experience -- I certainly have learned a lot! One of the most painful areas has in fact been the translating of HTML templates specifically because a template file is far too coarse a granularity. When I want to add a new widget to a template, I can usually figure out where to add it in say, the Spanish or French version, but it's nearly hopeless to try to add it to the Japanese version. :) Here, I hope Fred, Stephan Richter, and my efforts at i18n'ing Zope3's Page Templates will greatly improve things. It's early going but it feels right. It would mean you essentially have one version of the template but you'd mark it up to designate the translatable messages, and I think you'd end up integrating those with your Python source catalogs (but maybe in a different domain?). I'm not quite sure how that would translate to plaintext templates (e.g. for email messages). Input aspects are something neither MM nor Zope has (yet) adequately addressed. What I'm thinking of here are message footers in multiple languages or say, a job description in multiple languages. We'll have to address these down the road. I've already mentioned about efforts in Zopeland for localizing non-message issues. On-the-fly language selection is something that I have had to deal with in MM, and Python's class-based gettext API is essential here, and works well. Zope3 and MM take slightly different u/i tacks, with Zope3 doing better browser language negotiation and MM allowing for explicit overrides in forms. Some combination of the two is probably where web-based applications want to head. now-to-make-time-to-finish-MM2.1-ly y'rs, -Barry

Neil Hodgson wrote:

...

Not making bindings explicit may mean that translators use other variables available at the translation point leading to unexpected failures when internal details are changed.

Actually, I don't think that is the case. I think that the security implications of "_" are overstated. name = "Paul" country = "Canada" password = "jfoiejw" _('${name} was born in ${country}') The "_" function can use a regular expression to determine that the original code used only "${name}" and "${country}". Then it can disallow access to ${password} def _(origstring): orig_substitions = get_substitutions(origstring) translation = lookup_translation(origstring) translation_substitions = get_substitutions(translation_substitions) assert translation.substitutions == orig_substitutions Paul Prescod

Tim Peters wrote:

[Guido, quotes Christian]

...

...

The following statements are ordered by increasing hate. 1 - I do hate the idea of introducing a "$" sign at all. 2 - giving "$" special meaning in strings via a module 3 - doing it as a builtin function 4 - allowing it to address local/global variables

[and adds]

...

Doesn't 4 contradict your +1 on allvars()?

Since Christian's reply only increased the apparent contradiction, allow me to channel: they are ordered by increasing hate, but starting at the bottom. s/increasing/decreasing/ in his original, or s/hate/love/, and you can continue to read it in the top-down Dutch way <wink>.

Huh? Reading from top to bottom, as I used to, I see increasing numbers, which are in the same order as the "increasing hate" (not a linear function, but the same ordering). 4 - allowing it to address local/global variables is what I hate the most. This is in no contradiction to allvars(), which is simply a function that puts some variables into a dict, therefore deliberating the interpolation from variable access. Where is the problem, please? -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Tim Peters wrote:

[Tim]

...

...

Since Christian's reply only increased the apparent contradiction, allow me to channel: ...

[Christian Tismer]

...

Huh? Reading from top to bottom, as I used to, I see increasing numbers, which are in the same order as the "increasing hate" (not a linear function, but the same ordering).

4 - allowing it to address local/global variables is what I hate the most. This is in no contradiction to allvars(), which is simply a function that puts some variables into a dict, therefore deliberating the interpolation from variable access.

Where is the problem, please?

I was warming up my awesome channeling powers for Guido's impending vacation, and all I can figure is that I must have left them parked in reverse the last time he came back. Nothing a 12-pack of Coke didn't cure, though! I channel that you'll graciously accept my apology <wink>.

Whow! A TPA. Will stick it next to my screen :-) Well, the slightly twisted content of that message shaded its correct logic, maybe. Meanwhile, I'd like to drop that hate stuff and replace it by a little reasoning: Let's name locals/globals/whatever as "program variables". If there are program variables directly accessible inside strings to be interpolated, then I see possible abuse, if abusers manage to supply such a string in an unforeseen way. For that reason, I wanted to enforce that an explicit dictionary has to be passed as an argument, to remind the programmer that she is responsible for providing access. But at that time, I wasn't considering compile time string parsing. Compile time means the strings containing variable names are evaluated only once, and they behave like constants, cannot be passed in by a later intruder. That sounds pretty cool, although I don't see how this fits with I18n, which needs to change strings at runtime? Maybe it is possible to parse variable names out, replace them with some placeholders, and to do the internationalization after that, still not giving variable access to the final product. Example (now also allowing functions): name1 = "Felix" age1 = 17 name2 = "Hannes" age2 = 8 "My little son $name1 is $age1. $name2 is $(age2-age1) years older.".sub() --> "My little son Felix is 8. Hannes is 9 years older." This string might be translated under the hood into: _ipol = { x1: name1, x2: age1, x3: name2, x4: (age2-age1) } "My little son $x1 is $x2. $x3 is $x4 years older.".sub(_ipol) This string is now safe for further processing. Maybe the two forms should be syntactically different, but what I mean is a compile time transformation, that removes all real variables names in the first place. interpolation-is-by-value-not-by-name - ciao - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Barry A. Warsaw wrote:

...

...

...

...

...

"CT" == Christian Tismer writes:

CT> If there are program variables directly accessible inside CT> strings to be interpolated, then I see possible abuse, if CT> abusers manage to supply such a string in an unforeseen way.

For literal strings in .py files, the only way that's going to happen is if someone you don't trust is hacking your source code, /or/ if you have evil translators sneaking in bogus translation strings. The latter can be solved with a verification step over your message catalogs, while the former I leave as an exercise for the reader. :)

So still, I trust automatic interpolation of program vars for literal strings, but for strings coming from some other source (e.g. a web form), then yes, you obviously want to be explicit about the interpolation dictionary.

From another reply:

def whereBorn(name): country = countryOfOrigin(name) return _('$name was born in $country')

Ok, I'm all with it. Since a couple of hours, I'm riding the following horse: - $name, $(name), $(any expr) is just fine - all of this is compile-time stuff The idea is: Resolve the variables at compile time. Don't provide the feature at runtime. Here a simple approach. (I'm working on a complicated, too): (assuming the "e" character triggering expression extraction) def whereBorn(name): country = countryOfOrigin(name) return _(e'$name was born in $country') is accepted by the grammar, but turned into the equivalent of: def whereBorn(name): country = countryOfOrigin(name) return _('%(x1)s was born in %(x2)s') % { "x1": name, "x2": country} That is: The $ stuff is extracted, turning the fmt string into something anonymous. Your _() processes it, then the variables are formatted in. This turns the $ stuff completely into syntactic sugar. Any Python expression inside $() is allowed, it is compiled as if it were sitting inside the dict. I also believe it is a good idea to do the _() on the unexpanded string (as shown), since the submitted values are most probably hard to translate at all. cheers - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Paul Prescod wrote:

Christian Tismer wrote:

...

...

Ok, I'm all with it. Since a couple of hours, I'm riding the following horse:

- $name, $(name), $(any expr) is just fine - all of this is compile-time stuff ....

I think you just described PEP 215. But what you're missing is that we need a compile time facility for its flexibility and simplicity but we also need a runtime facility to allow I18N.

Are you sure you got what I meant? I want to compile the variable references away at compile time, resulting in an ordinary format string. This string is wraped by the runtime _(), and the result is then interpolated with a dict.

...

I also believe it is a good idea to do the _() on the unexpanded string (as shown), since the submitted values are most probably hard to translate at all.

_ runs at runtime. If the interpolation is done at compile time then "_" is executed too late.

Compile time does no interpolation but a translation of the string into a different one, which is interpolated at runtime. will-read-PEP215-anyway - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

Paul Prescod wrote:

Christian Tismer wrote:

...

...

Are you sure you got what I meant? I want to compile the variable references away at compile time, resulting in an ordinary format string. This string is wraped by the runtime _(), and the result is then interpolated with a dict.

How can that be?

Original expression:

_($"$foo")

Expands to:

_("%(x1)s"%{"x1": foo})

Standard Python order of operations will do the %-interpolation before the method call! You say that it could instead be

_("%(x1)s")%{"x1": foo}

But how would Python know to do that? "_" is just another function. There is nothing magical about it. What if the function was instead re.compile? In that case I would want to do the interpolation *before* the compilation, not after!

Are you saying that the "_" function should be made special and recognized by the compiler?

As you say it, it looks a little as if something special would be needed, right. I have no concrete idea. Somehow I'd want to express that a function is applied after compile time substitution, but before runtime interpolation. Here a simple idea, while not very nice, but it could work: Assume a "$" prefix, which does the interpolation in the way you said. Assume further a "%" prefix, which does it only halfway, returning a tuple: (modified string, dict). This tuple would be passed to _(), and it is _()'s decision to work this way: def _(s): if type(s) == type(()): s, args = s else: args = None #... processing s ... if args: return s % args else: return s But this is a minor issue, I just wanted to tell what I think should happen, without giving an exact solution. cheers - chris -- Christian Tismer :^) mailto:tismer@tismer.com Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

[Guido, quotes Christian]

...

...

The following statements are ordered by increasing hate. 1 - I do hate the idea of introducing a "$" sign at all. 2 - giving "$" special meaning in strings via a module 3 - doing it as a builtin function 4 - allowing it to address local/global variables

[and adds]

...

Doesn't 4 contradict your +1 on allvars()?

[Tim]

Since Christian's reply only increased the apparent contradiction, allow me to channel: they are ordered by increasing hate, but starting at the bottom. s/increasing/decreasing/ in his original, or s/hate/love/, and you can continue to read it in the top-down Dutch way <wink>.

template = [ '$linenum - I do $feeling the idea of introducing the "$$" sign at all.', '$linenum - give "$$" special meaning in strings via a module', '$linenum - doing it as a builtin function' '$linenum - allowing it to address/global local variables' ] feeling = 'hate' if 'Dutch' in options: feeling = 'love' template = template[::-1] # cool new feature print 'The following statements are ordered by increasing $feeling.'.sub() for cnt, line in enumerate(template): # cool new feature linenum = cnt+1 # still wish enumerate had an optional start arg print linenum.sub() # aspiring cool new feature 'regnitteh dnomyar'[::-1]

On 19 Jun 2002 at 22:30, Guido van Rossum wrote:

The $ means "substitution" in so many languages besides Perl that I wonder where you've been.

It doesn't mean anything in any language I *like*. -- Gordon http://www.mcmillan-inc.com/

On 20 Jun 2002 at 15:34, Fredrik Lundh wrote:

gordon wrote:

...

...

The $ means "substitution" in so many languages besides Perl that I wonder where you've been.

It doesn't mean anything in any language I *like*.

not even in american?

Where $ means "dough", which is one letter different from "cough" and "tough"[1]? the-world's-best-language-for-discussing- the-price-of-oranges-ly y'rs -- Gordon http://www.mcmillan-inc.com/ [1] If you're old-fashioned enough, you can spell "plow" as "plough", too.

On Thu, Jun 20, 2002, François Pinard wrote:

[Barry A. Warsaw]

...

In any event, allvars() or a-different-vars() is out of scope for this PEP. We'd use it if it was there, but I think it needs its own PEP, which someone else will have to champion.

On the other hand, the allvars() suggestion is right on the point in my opinion. It is not a stand-alone suggestion, its goal was to stress out that `.sub()' is too far from the `%' operator, it looks like a random addition. The available formatting paradigms of Python, I mean, those which are standard, should look a bit more unified, just to preserve overall elegance. If we want Python to stay elegant (which is the source of comfort and pleasure, these being the main goals of using Python after all), we have to seek elegance in each Python move.

+1 -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Project Vote Smart: http://www.vote-smart.org/