New-style string formatting

[Skip Montanaro]

    >> Here are a couple counterarguments:
    >> * Who died and made string interpolation king?  In other words, why
    >> should "..."(args) be interpreted as string interpolation and not
    >> "...".replace(args)?

    Gerrit> I don't think this is a really valid argument, because exactly
    Gerrit> the same is true for string interpolation using the % character.

Yes, except for history.  That is, I have the benefit of arguing from the
position that "..."%(args) is already in place.  Had that construct not
already existed in the language, you and I would be on equal footing
here. :-)

    >> * What's intuitive about calling a string?

    Gerrit> Exactly as much as there is intuitive on modulo'ing a string.

True.

    >> There's nothing mnemonic in the construct to suggest what you want to
    >> do.

    Gerrit> True. Mnemonic would be to create a ".format" method.

According to the definition I found for "mnemonic" via Google, as an
adjective it means:

    Relating to, assisting, or intended to assist the memory.

In that sense, "%" is mnemonic for me because it reminds me of the %-strings
in C printf() format strings.  "format" is descriptive.  It would probably
be as good a choice as either syntactic construct, largely because it's more
explicit and requires less knowledge of convention or printf().

    >> The % operator at least has the syntactic connection to C's printf()
    >> function.

    Gerrit> The syntactic connection goes as far as the % as a formatting
    Gerrit> character.  I don't know C very well, but AFAIK, % is not an
    Gerrit> operator for strings (character sequences) in C.

Nope, but ignoring the %(key)s form added to Python, the meaning of Python's
format strings and printf()'s are almost identical.

    Gerrit> CMIIW,
            ???
    Gerrit> but printf's first argument corresponds to Python's % left hand
    Gerrit> operand, and printf's second argument corresponds to Python's %
    Gerrit> right hand operand.

    Gerrit> So, where _does_ the % as string operator come from?

Only that it is mnemonic - suggestive of printf()'s format character.  Like
I said above, I have history on my side. "..."%(args) already exists in the
language and is not likely to disappear.  If it didn't, your proposal would
be much stronger.

    >> * This idea doesn't extend to dictionary interpolation

    Gerrit> It does: see my other message: "..."(**d) and "..."(*s).

Yes, thanks.

    >> * There's already a perfectly good way to do it: "..."%(args).

    Gerrit> True. This works very well.

    >> Adding another way that only saves a single character and goes
    >> against the Pythonic grain of having generally one way to do things.

    Gerrit> True. I am not sure about it yet, because different Zen of
    Gerrit> Python advices contradict each other here.
    Gerrit> + "Beatiful is better than ugly": I find the % not very beatiful.

I think the operator-vs-call() is kind of a toss-up here.

    Gerrit> + "Simple is better than complex": % does complicate a little
    Gerrit>   bit.  

Microscopically?

    Gerrit> - "There should be one-- and preferably only one --obvious way
    Gerrit>   to do it."  ...but what is obvious? It's only what we're used
    Gerrit>   too - does that mean it's the best?

I don't know when "..."%(args) was added to the language (before I began
using it the mid-1994 timeframe), but the mechanism, if not the precise
form, was clearly obvious to Guido.  After all, he did write Python in C.

    Gerrit> + "If the implementation is easy to explain, it may be a good
    Gerrit>   idea." 

I don't think one is really easier to explain than the other.

In general, when proposing to replace one construct of the language with
another, Guido often raises some barriers:

    * code breakage - "..."(args) clearly wouldn't break anything, since
      it's currently syntactically invalid.

    * invalidation of a substantial body of knowledge - in this case, no
      Python book mentions any syntactic construct like "..."(args). [1]
      "..."(args) would clearly get used, so people would look to their
      current books and find them lacking.

    * does it significantly increase of expressive power or clarity of the
      language?  No matter that you like "..."(args) better than
      "..."%(args), the former is is clearly not head and shoulders better
      than the latter in this respect. [2]

In some sense you have two strikes against you.  I don't see "..."(args)
clearing either the second or third barriers.

Skip

[1] That's like me not being able to use my Camel book (Perl v4) to learn
how to use Perl's references (new in Perl v5).  My Camel book is thus
generally worthless to me because it doesn't help me make my Perl code look
like Python. ;-)

[2] Aside: Would "..."(args) be more efficient than "..."%(args)?