[Python-3000] PEP 3101 update

[Guido van Rossum]

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

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

--Guido

On 6/14/06, Talin <talin at acm.org> wrote:
> 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
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)