[Python-3000] PEP 3101 update

[Talin]

Guido van Rossum wrote:
> On 6/20/06, Talin <talin at acm.org> wrote:
> 
>> While you are here, I'd like to ask a couple questions:
>>
>> 1) Do you have any reaction to Brett Cannon's idea that we add a second,
>> optional argument to str() that accepts exactly the same conversion
>> specifier syntax? Should I incorporate that into the PEP, or should that
>> be a separate PEP?
> 
> 
> Not so keen. This seems to be a completely different use of str(). If
> we want that API it should be called something else. I don't see an
> advantage of overloading str().

Before we dismiss that too quickly, let me do a better job of explaining 
the general idea.

The motivation for this is converting an arbitrary value to string form 
- which is exactly what str() does. Only in this case, we want to be 
able to have some control over the formatting of that string.

Converting single values to strings using operator % looks something 
like this:

    s = "%2.2g" % f

With str.format(), the single-conversion case gets a bit more wordy:

    s = "{0:2.2g}".format( f )

Instead of all that, why not allow the conversion to be passed to the 
str() constructor directly:

    s = str( f, "2.2g" )

It doesn't actually have to be called "str", you could say, for example:

    s = str.convert( f, "2.2g" )

However, the str() form is more concise and more readable than any of 
the alternatives presented here. I think it's pretty clear what is 
intended (especially since C# has a similar syntax for its "ToString()" 
method.)

In any case, I think there's a pretty good argument that one ought to be 
able to convert single values without having to embed them as fields 
within a string template.

Now, my personal motive for this is that it allows me to cut my PEP in 
half - because the logic of the conversion specifiers can be isolated 
and used directly, without having to go through format().

-- Talin