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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
