[Python-3000] Updating PEP 3101

[Eric V. Smith]

Talin wrote:
> Some more thoughts on this, and some questions.
> 
> PEP 3101 defines two layers of APIs for string formatting: a low-level 
> formatting engine, and a high-level set of convenience methods 
> (primarily str.format).
> 
> Both layers have grown complex due to the desire to satisfy feature 
> requests that have been asked for by various folks. What I would like to 
> do is move the design back to a more OOWTDI style.
> 
> The way I propose to do this is to redesign the low-level engine as a 
> class, called Formatter, with overridable methods.

I think this is a good idea, in order to keep "str".format() really
simple, and thereby increase its usage.

> To support the high-level API, there will be a single, built-in global 
> singleton instance of Formatter. Calls to str.format will simply be 
> routed to this singleton instance.

I'm not so sure this is actually required, see below.

> So my first question is to get a sense of how many people would find 
> that agreeable. In other words, is it reasonable to require people to 
> give up the syntactical convenience of "string".format() when they want 
> to do custom formatting?

I like keeping "str".format() simple, because I see it's main use as a
slightly more flexible version of '%' for strings.  I hope it's usage
will be ubiquitous.  It's especially handy for i18n.

> My second question deals with implementation. Because 'str' is a 
> built-in type, all of its methods must be built-in as well, and 
> therefore implemented in C. If 'str' depends on a built-in formatter 
> singleton instance, that singleton instance must also be implemented in 
> C, and must be initialized in the Parser before any calls to str.format.

I don't think there actually needs to be a built-in singleton formatter,
but it just needs to appear "as-if" there is one.  Not having a
singleton makes hiding the singleton a non-issue.  It also simplifies
the C code.  str.format could be implemented in C, using the existing
code in the sandbox implementation.  The Formatter class could be
written in C or Python, and would call some of the existing code in the
sandbox implementation, or refactored versions if we need to expose
anything else (which I don't think we do).

The only real work we'd need to do to the sandbox code is to strip out
some of the code that implements the additional options (such as
multiple syntaxes) and hook up str.format.  Once we reach a consensus,
I'm ready to put some time into this.  Then we'd have to implement
Formatter, of course.  But it shouldn't be too hard.

One comment I'd like to make on your prior email is that I'd like to see
this implemented in 2.6.  To my knowledge, we're not removing any
functionality in 3.0 that will be replaced by str.format, so I can't
argue that it will make it easier to have code that runs in both 2.6.
and 3.0.  But it seems to me that the fewer new feature that exist only
in 3.0, the easier it will be to wrap you head around 3.0.

Eric.