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

[Josiah Carlson]

"Patrick Maupin" <pmaupin at gmail.com> wrote:
[snip]
> Feature:  Alternate syntaxes for escape to markup.
[snip]
> 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 think this is reasonable.


> 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

Sounds far too implicit to me.  I would much prefer a completely
different syntax.  Having just had a patch that implements Windows shell
variable expansion as $var, ${var} and %var% (the last being new), I
can't help but think that %var% would be a better alternate explicit
syntax than the 'space follows {' implicit syntax you are offering.

[snip]
> Feature:  Automatic search of locals() and globals() for name lookups
> if no parameters are given.

-1

for the obvious 'Explicit is better than implicit'.


> Feature: Ability to pass in a dictionary or tuple of dictionaries of
> namespaces to search.

+1

I can see where it would be useful for code using something like
"...".format(obj.__dict__, defaults)


[snip]
> Feature: Addition of functions and "constants" to string module.
> 
> The PEP proposes doing everything as string methods, with a "cformat"
> method allowing some access to the underlying machinery.  I propose
> only having a 'format' method of the string (unicode) type, and a
> corresponding 'format' and extended 'flag_format' function in the
> string module, along with definitions for the flags for access to
> non-default underlying format machinery.

Sounds good to me.


> Feature: Ability for "field hook" user code function to only be called
> on some fields.
> 
> The PEP takes an all-or-nothing approach to the field hook -- it is
> either called on every field or no fields.  Furthermore, it is only
> available for calling if the extended function ('somestring'.cformat()
> in the spec, string.flag_format() in this proposal) is called.  The
> proposed change keeps this functionality, but also adds a field type
> specifier 'h' which causes the field hook to be called as needed on a
> per-field basis.  This latter method can even be used from the default
> 'somestring'.format() method.
> 
> 
> Changed feature: By default, not using all arguments is not an exception

+1

I can see how it would be useful to have '...'.format(obj.__dict__) to
format portions of some object.  Requiring the explicit passing of names,
and/or the construction of a new dictionary would be foolish.
Practicality beats purity.


> Feature:  Ability to insert non-printing comments in format strings
> 
> This feature is implemented in a very intuitive way, e.g. " text {#
> your comment here} more text" (example shown with the default
> transition to markup syntax).  One of the nice benefits of this
> feature is the ability to break up long source lines (if you have lots
> of long variable names and attribute lookups).

-1

The user can use the parser/compiler to get this behavior for free.

    (" text " #your comment here
     "more text").format(...)


> Feature:  Exception raised if attribute with leading underscore accessed.
> 
> The syntax supported by the PEP is deliberately limited in an attempt
> to increase security.  This is an additional security measure, which
> is on by default, but can be optionally disabled if
> string.flag_format() is used instead of 'somestring'.format().

+1


> Feature: Support for "center" alignment.
> 
> The field specifier uses "<" and ">" for left and right alignment.
> This adds "^" for center alignment.

+.5

There is use for this, but I'm not sure that '^' is as clear as '<' or
'>' in the left/right alignment case.  Its meaning certainly doesn't
jump out to me as 'center' (then again, < and > don't jump out as left
and right alignment either...).


> Feature: support of earlier versions of Python

+1

> Feature: no global state
> 
> The original PEP specified a global error-handling mode, which
> controlled a few capabilities.  The current implementation has no
> global state -- any non-default options are accessed by using the
> string.flag_format() function.

Great.  Global state is a great way of having things break when threads
get involved.

 - Josiah