[Python-3000] PEP 3101 update

[Talin]

Nick Coghlan wrote:
>> Conversion Specifiers

By the way, good feedback. I've incorporated most of the text changes 
into the PEP. I'd like to discuss a few of your suggestions in more 
detail before proceeding.

>>      There are several integer conversion types. All invoke int() on
>>      the object before attempting to format it.
> 
> 
> Having another look at existing str-% behaviour, this should instead say:
> 
>       There are several integer conversion types. All will raise TypeError
>       if the supplied object does not have an __index__ method.

This is a new 2.5 feature, correct?

>>      There are several floating point conversion types. All invoke
>>      float() on the object before attempting to format it.
> 
> 
> Similar to integers, this should instead say:
> 
>       There are several floating point conversion types. All will raise
>       TypeError if the supplied object is not a float or decimal instance.

This seems to close off opportunities for type-punning, which some on 
this list have asked for. If you want to print an int as a float, well, 
why not?

>> Controlling Formatting
> 
> 
> I'm becoming less and less satisfied with the idea that to get a string 
> version of a float, I do this:
> 
>   x = str(val)
> 
> But if I want to control the precision, I have to write:
> 
>   x = "{0:.3}".format(val)  # Even worse than the current "%.3f" % val!!

I've been thinking about this very issue. A lot.

I noticed that PyString_Format has a lot of internal functionality which 
has no pure-python equivalent. Like you say, it would be nice to have a 
simple method to format a single scalar value. I wasn't thinking about 
adding a parameter to str(), but instead some newly-named function (e.g. 
'format'), although I realize that has compatibility problems. I think 
that a second param to str() is better; however, you will have to 
compete against any other possible claims for that valuable second 
parameter.

As an aside, have a look at this function which I was just now working 
on. I'm not entirely sure it is correct, but I think you can see the 
motivation behind it:

# Pure python implementation of the C printf 'e' format specificer
def sci(val,precision,letter='e'):
     sign = ''
     if val < 0:
         sign = '-'
         val = -val
     exp = int(floor(log(val,10)))
     val *= 10**-exp
     if val == floor(val):
         val = int(val)
     else:
         val = round(val,precision)
         if val >= 10.0:
             exp += 1
             val = val * 0.1
     esign = '+'
     if exp < 0:
         exp = -exp
         esign = '-'
     if exp < 10: exp = '0' + str(exp)
     else: exp = str(exp)
     return sign + str(val) + letter + esign + exp


> Why can't I instead write:
> 
>   x = str(val, ".3")
> 
> IOW, why don't we change the signature of 'str' to accept a conversion 
> specifier as an optional second argument?
> 
> Then the interpretation of conversion specifiers in format strings is 
> straightforward - the conversion specifier becomes the second argument 
> to str().

So my only question then is: What about classes that override __str__? 
Do they get the conversion specifier or not?

One way to resolve this would be to go even further and bury the call to 
__format__ inside str! In other words, if you pass a second argument to 
str(), it will first check to see if there's a __format__ function, and 
if not, then it will fall back to __str__.

> Then it would be str() that does the dispatch of the standard conversion 
> specifiers as described above if __format__ is not provided.

My biggest concern about this is that PEP 3101 is getting kind of large, 
because we keep thinking of new issues related to string formatting. I'm 
wondering if maybe this idea of yours could be split off into a separate 
PEP.

Other than that, I think it's a pretty good idea.

-- Talin