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