I have not yet posted the PEP 3101 - Advanced String Formatting to c.l.p. yet because I am still in the process of collecting feedback from python-dev. My plan is to do a slow escalation of feedback collection over the course of the next several weeks; As I see it, there's really no hurry about this.
I would like to list some of the issues that have been brought up. In particular, I would like to get to a definative resolution on some of these issues. Issue: Compound Field Names In the draft version of the PEP, I proposed a scheme whereby a limited set of Python expressions could be embedded into a string template. The list of operations was deliberately limited for security reasons. The reaction to this was mixed, so I took it out of the proposal. However, I realized that some form of naming indirection might provide a way out of the dict-flattening dilemma. In particular, Ian Bicking was a strong proponent of retaining the existing % operator's ability to pass in a regular dictionary as an argument, and allow the formatting string to cherry-pick specific values out of it, rather than having to explicitly pass in exactly the values. The **args syntax allows this, but requires the dictionary to be copied. A strong argument was made for a non-copying method for accessing the values in a dictionary. Various special case solutions were proposed (such as implicitly interpreting the first argument, special method names, special keywords, etc.) all of which I felt were rather hackish (even the ones I suggested.) As a way out of this dilemma, I decided to re-introduce a simplified form of the compound field names idea, which would allow individual dictionary entries to be addressed independently. However, there have been objections about the ambiguity of the syntax, since it supports both item and attribute access. There have also been a lot of "all or nothing" arguments (i.e. 'why support only this one type of operator, and not the others? I think you should support them all, or don't support any'), but frankly I don't put too much weight on this line of reasoning. Issue: Escaping Braces The primary reason for using backslash as an escape was that it seemed more 'Pythonic' to me; In addition, I wanted to be able to support nested braces so that the format fields could themselves be parameterized (since the current operator % supports a limited form of parameterization.) I don't have an objection to using doubled braces as an escape, provided that someone can come up with a reasonably simple algorithm for deciding when a brace is nested and when it is escaped. Issue: Exact syntax for conversion specifiers The current spec says that the conversion specifiers will be "the same as the existing operator %", with some exceptions. Do I need to go and explicitly spell out what specifiers are supported, and what their syntax is? That will make the PEP rather large, IMHO. (BTW, for those who asked - I call them conversion specifiers because that's the term used in the current docs for operator %.) Issue: Custom formatting I'm in the process of rewriting this section to make it clearer. I feel that being able to customize the formatting of a given data type is important, particularly for complex types such as sets and lists. A trivial example is being able to display negative integers in parentheses, as is done in accounting, rather than using a minus sign. Issue: Target version Neither this PEP or the Keyword-only PEP breaks backwards compatibility, so it has been suggested that these PEPs be applied to 2.6 instead of 3.0, or perhaps developed in 3.0 and then backported. If this is the case, should the PEPs be renumbered? Issue: Implementation While I am willing to do the basic implementation of this PEP, I would rather that someone with a greater experience with the internals of Python do the final version; My experience with hacking the Python C code is rather limited at this point, and in the last month I've run into a number of situations where my instincts about how to do things turned out to be wrong. The actual implementation should be fairly straightforward, and the only tricky part is re-implementing the behaviors of the current conversion specifiers. -- 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
