[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