[Python-3000] PEP 3101 update
talin at acm.org
Tue Jun 20 20:21:49 CEST 2006
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
> (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?
More information about the Python-3000