[Python-3000] Proposed changes to PEP3101 advanced string formatting -- please discuss and vote!

[Jerry Seutter]

On 3/12/07, Patrick Maupin <pmaupin at gmail.com> wrote:
>
> Eric Smith and I have a reasonable first-cut of a C implementation for
> Talin's PEP3101 (it runs as an extension module and has been tested on
> Python 2.3,  2.4, and 3.0) along with some test cases.  It's sort of
> experimental, in that it mostly implements the PEP, but also
> implements a few possible enhancements and changes, to give us (well,
> me, mostly) an idea of what works and what doesn't, and ideas about
> changes that might be useful.
>
> This list of potential changes to the PEP is in order of (what I
> believe to be) most contentious first.  (It will be interesting to
> contrast that with the actual votes :).  I apologize for the long
> list, but it's quite a comprehensive PEP, and the implementation work
> Eric and I have done has probably encompassed the most critical
> examination of the PEP to date, so here goes:
>
>
> Feature:  Alternate syntaxes for escape to markup.
>
> There is naturally a strong desire to resist having more than one way
> to do things.  However, in my experience using Python to generate lots
> of text (which experience is why I volunteered to work on the PEP
> implementation in the first place!), I have found that there are
> different application domains which naturally lend themselves to
> different approaches for escape to markup.  The issues are:
>
>    - In some application domains, the number of {} characters in the
> actual character data is dizzying.  This leads to two problems: first
> that there are an inordinate number of { and } characters to escape by
> doubling, and second (and even more troubling) is that it can be very
> difficult to locate the markup inside the text file, without an editor
> (and user!) that understands fancy regexps.
>
> - In other application domains, the sheer number of {} characters is
> not so bad (and markup can be readily noticed), but the use of {{ for
> { is very confusing, because { has a particular technical meaning
> (rather than just offsetting some natural language text), and it is
> hard for people to mentally parse the underlying document when the
> braces are doubled.
>
> To deal with these issues, I propose having a total of 3 markup
> syntaxes, with one of them being the default, and with a readable,
> defined method for the string to declare it is using one of the other
> markup syntaxes.  (If this is accepted, I feel that EIBTI says the
> string itself should declare if it is using other than the standard
> markup transition sequence.  This also makes it easier for any
> automated tools to understand the insides of the strings.)
>
> The default markup syntax is the one proposed in the initial PEP,
> where literal { and } characters are denoted by doubling them.  It
> works well for many problem domains, and is the best for short strings
> (where it would be burdensome to have the string declare the markup
> syntax it is using).
>
> The second method is the well-understood ${} syntax.  The $ is easy to
> find in a sea of { characters, and the only special handling required
> is that every $ must be doubled.



I like ${}.  I have admired Ruby's #{} when I've had to use it, as it is
easy to read.  It kind of reminds me of #!/bin/sh in shell scripts,
reminding me that it is something magic.

Disclaimer:  I know nothing of the consequences to enabling this.

Jerry Seutter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070312/422b8135/attachment.htm