On 3/12/07, Patrick Maupin <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
