[Python-3000] Proposed changes to PEP3101 advanced string formatting -- please discuss and vote!
Aahz
aahz at pythoncraft.com
Tue Apr 3 21:15:35 CEST 2007
On Mon, Mar 12, 2007, Patrick Maupin wrote:
>
> Feature: Alternate syntaxes for escape to markup.
>
> 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.
-0
> The third method is something I came up with a couple of years ago
> when I was generating a lot of C code from templates. It would make
> any non-Python programmer blanch, because it relies on significant
> whitespace, but it made for very readable technical templates. WIth
> this method "{foo}" escapes to markup, but when there is whitespace
> after the leading "{", e.g. "{ foo}", the brace is not an escape to
> markup. If the whitespace is a space, it is removed from the output,
> but if it is '\r', '\n', or '\t', then it is left in the output. The
> result is that, for example, most braces in most C texts do not need
> to have spaces inserted after them, because they immediately precede a
> newline.
-1
> Feature: Automatic search of locals() and globals() for name lookups
> if no parameters are given.
-1 -- make it a flag for string.format() or use a different function
name.
> Feature: Placement of a dummy record on the traceback stack for
> underlying errors.
+1
> Changed feature: By default, not using all arguments is not an exception
-0 for *args, +1 for **kwargs
While I understand your reasoning, I still think that mismatched strings
and arguments is likely to be a significant problem; instead I favor
allowing this feature to be turned off.
> Feature: Exception raised if attribute with leading underscore accessed.
+1
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/
Need a book? Use your library!
More information about the Python-3000
mailing list