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