[Python-3000] PEP 3101 update

[Talin]

Rudy Rudolph wrote:
> Center- and decimal-align nicely round out the left-align,
> right-align, and pad-after-sign formatting already proposed,
> and are easy to implement. I therefore ask that they be added
> to the PEP. BTW, I very much like the proposal in the PEP.

The basic idea of a decimal align option sounds good to me. I even 
started working up an implementation, but I haven't had the time to 
finish it -- I decided to go with the '^' character as an alignment symbol.

Greg Ewing's point that this is effectively the same as "pad with 
spaces" is correct, however I don't think that's the way most people 
think of it - in other words, generally what people ask for is "line up 
all the decimal points".

Here's my concern however: PEP 3101 is getting rather large, because of 
all of these little details that are ancilliary to the primary proposal 
of a 'format' method for string objects. I've already pushed back on 
Nick Coghlan's otherwise excellent suggestion of allowing the same set 
of conversion specifiers to be used as a second argument to str() for 
this reason.

(I thought about breaking out the conversion specifiers into a separate 
PEP, but since they aren't meaningful by themselves it makes no sense to 
accept one PEP and reject another, and also because then I'd have 3 PEPs 
in the Python-3000 queue [including 3102], and right now 2 is as much as 
I want to deal with.)

Because 3101 is targeted at Python-3000, and because 3000 is scheduled 
for release in the distant future, I have no sense as to what the 
timetable is for acceptance or adoption of this PEP; As far as I know, 
it could be a year or more before a decision is made, and the PEP might 
be rejected at the end of that time. So from my point of view, I am 
faced with the prospect of an ever-expanding PEP as people continue to 
think of new suggestions over the course of the next year, all of which 
may come to naught.

My feeling is that a good PEP should contain a limited number of BDFL 
decisions - that is, it should be possible for Guido to go down the 
checklist and accept / reject / suggest changes to a small number of 
essential bullet points. I fear that PEP 3101 is going to turn into a 
kind of omnibus bill with all kinds of little amendments to deal with.

For this reason, I'd like to put some sort of limit on lower-level 
details of the PEP, and let that detail be filled in via the normal 
feature request / patch submission process once the PEP has actually 
been accepted.

I guess what I also need to do is find some place to post my prototype 
so that people can criticize it and submit patches to it. What would be 
ideal for my purposes would be if there was a "research" branch in the 
Python svn so that wild-eyed radicals such as myself could check in code 
that is still being discussed by the community and is not yet intended 
for inclusion in the main tree. This would also allow people who have 
suggestions to submit patches to the prototype, rather than having to 
ask me to do it for them.

-- Talin