[Python-3000] PEP 3101 Open Issues

[Talin]

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