[Python-3000] More PEP 3101 changes incoming
talin at acm.org
Sun Aug 12 19:00:55 CEST 2007
Eric V. Smith wrote:
> Talin wrote:
>> One final thing I wanted to mention, which Guido reminded me, is that
>> we're getting short on time. This PEP has not yet been officially
>> accepted, and the reason is because of the lack of an implementation.
>> I don't want to miss the boat. (The boat in this case being Alpha 1.)
> I have hooked up the existing PEP 3101 sandbox implementation into the
> py3k branch as unicode.format(). It implements the earlier PEP syntax
> for specifiers.
Woo hoo! Thanks Eric. This is great news.
At some point I'd like to build that branch myself, I might send you
> I'm going to work on removing some cruft, adding tests, and then slowly
> change it over to use the new proposed specifier syntax.
I'm not sure that I'm happy with my own syntax proposal just yet. I want
to sit down with Guido and talk it over before I commit to anything.
I think part of the difficulty that I am having is as follows:
In writing this PEP, it was never my intention to invent something brand
new, but rather to find a way to cleanly merge together all of the
various threads and requests and wishes that people had expressed on the
subject. (Although I will admit that there are a few minor innovations
of my own, but they aren't fundamental to the PEP.)
That's why I originally chose a format specifier syntax which was as
close to the original % formatting syntax as I could manage. The idea
was that people could simply transfer over the knowledge from the old
system to the new one.
The old system is quite surprising in how many features it packs into
just a few characters worth of specifiers. (For example, I don't know if
anyone has noticed the option for putting a space in front of positive
numbers, so that negative and positive numbers line up correctly when
using fixed-width fields.)
And some of the suggested additions, like centering using the '^'
character, seemed to fit in with the old scheme quite well.
However, the old syntax doesn't fit very well with the new requirements:
the desire to have the 'repr' option take precedence over the
type-specific formatter, and the desire to split the format specifier
into two parts, one which is handled by the type-specific formatter, and
one which is handled by the general formatter.
So I find that I'm having to invent something brand new, and as I'm
writing stuff down I'm continually asking myself the question "OK, so
how is the typical Python programmer going to see this?" Normally, I
don't have a problem with this, because usually when one is doing an
architectural design, if you look hard enough, eventually you'll find
some obviously superior configuration of design elements that is clearly
the simplest and best way to do it. And so you can assume that everyone
who uses your design will look at it and see that, yes indeed, this is
the right design.
But with these format strings, it seems (to me, anyway) that the design
choices are a lot more arbitrary and driven by aesthetics. Almost any
combination of specifiers will work, the question is how to arrange them
in a way that is easy to memorize.
And I find I'm having trouble envisioning what a typical Python
programmer will or won't find intuitive; And moreover, for some reason
all of the syntax proposals, including my own, seem kind of "line-noisy"
to me aesthetically, for all but the simplest cases.
This is made more challenging by the fact that the old syntax allowed so
many options to be crammed into such a small space; I didn't want to
have the new system be significantly less capable than the old, and yet
I find it's rather difficult to shoehorn all of those capabilities into
a new syntax without making something that is either complex, or too
verbose (although I admit I have a fairly strict definition of verbosity.)
Guido's been suggesting that I model the format specifiers after the
.Net numeric formatting strings, but this system is significantly less
capable than %-style format specifiers. Yes, you can do fancy things
like "(###)###-####", but there's no provision for centering or for a
custom fill character.
This would be easier if I was sitting in a room with other Python
programmers so that I could show them various suggestions and see what
their emotional reactions are. I'm having a hard time doing this in
isolation. That's kind of why I want to meet with Guido on this, as he's
good at cutting through this kind of crap.
More information about the Python-3000