[Python-3000] More PEP 3101 changes incoming

[Talin]

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 
questions later.

> 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.

-- Talin