[Python-3000] PEP 3101 update

[Talin]

Guido van Rossum wrote:
> Hi Talin,
> 
> Here's how I see it.
> 
> The probability of this PEP being accepted doesn't really depend on
> whether that particular proposed feature is present. Given all
> possible proposed features, it's probably better to err on the side of
> exclusion -- a PEP like this is more likely to be rejected due to
> excessive baggage than due to lack of functionality, as long as it
> covers all the functionality it's replacing. So, I'm with you: try to
> get the PEP implemented and accepted before adding too many new
> features. Once there's an accepted framework, it's easier to add
> features.
> 
> (Perhaps there's one use for this particular proposed feature; since
> it requires adding yet another parameter to certain formatting
> functions, it would be a good test for the generality of the API.
> Personally, I wonder if at some point we'll want to pass an arbitrary
> argument list, and/or keyword args? That would be a more useful
> feature to add to consider for the PEP than a specific decimal
> alignment, since it is a feature in support of extensibility.)

Well, one of the design goals for conversion specifiers is conciseness. 
I suspect you would get a lot of complaints if the conversion specifiers 
grew much longer than they currently are. So its a balancing act between 
compressability and readability.

There are two reasons for this: First, TOOWTDI. Anything you can do with 
a conversion specifier can be done by pre-processing the parameter that 
you pass into the format function. Allowing arbitrary conversion syntax 
would essentially mean creating a new language-within-a-language that 
would duplicate functionality that is better expressed by function calls.

Secondly, the conversion specifiers should not visually dominate or 
distract from the format string. That is, when reading the format 
string, you should be able to mentally skip over the conversion strings 
without too much trouble. This is much easier if they are short.

So in other words, I'm not trying to make the most general API possible, 
what I am doing instead is looking for various "low hanging fruit", that 
is useful features that can be expressed in one or two characters 
without sacrificing overall readability. Anything that requires more 
than that should be done by function calls.

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?

2) What's your feeling (and this isn't just directed at you) about 
having a sandbox area in the svn repository that's open to general 
modification, kind of like the code version of a wiki? Or, to put it 
another way, what's the best place to put my code so that people have 
the ability to hack on it?

-- Talin