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

Josiah Carlson jcarlson at uci.edu
Wed Mar 14 00:21:34 CET 2007

"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{} syntax. The 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, 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 'flagformat' 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.flagformat() 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.flagformat() 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.flagformat() function.

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

More information about the Python-3000 mailing list