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

[Jim Jewett]

On 3/12/07, Patrick Maupin <pmaupin at gmail.com> wrote:

> Feature:  Alternate syntaxes for escape to markup.

I suggest keeping this for templates, or at most the library, because ...

> using decorator-style  markup, e.g. {@syntax1} inside the string,

This is effectively a command switch.  It isn't part of the string's
data (it shouldn't display) or the template (it isn't replaced).  It
is just metadata -- and by the time you need that, the complexity is
probably enough to justify using a Template.

I also don't think you can improve on this, except possibly with a new
prefix, like

    $" ... "   # ${}
    _" ... "   # space-replace
    T" ... "   # sugar for string.Template(" ... ") with % mapped to
safe_substitute

Each of those look OK on their own, but I'm not sure they're important
enough to justify the extra complexity in the language as a whole.
(And if the T prefix already existed, I'm not sure you would have felt
as motivated to do this extension.)

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

I do like the search of locals().  It feels more like a guilty
pleasure than a good idea, though.  Maybe if it were phrased as a
call?

    print "At round {count} the value is {myvar}"()

Still feels more like a guilty pleasure than a good idea.

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

I would like this even if nothing else were adopted.

But do you mean "sequence of mappings", or exactly a tuple?  If you
mean exactly a tuple, that needs to be called out clearly in the
docstring as well as the docs.  If you mean any sequence, then you get
the same nasty "Is it a mapping or a sequence of mappings?" problem
that requires special-casing for singleton tuples today.

> Feature:  Placement of a dummy record on the traceback stack for
> underlying errors.
...
> The text associated with these internally generated ValueError
> exceptions will indicate the location of the exception inside  the
> format string, as well as the nature of the exception.

Yes, please.

> There is currently no general mechanism for non-Python source code to
> be added to a traceback (which might be the subject of another PEP),

Yes, please.  :D

> Feature: Addition of functions and "constants" to string module.

Yes.  Though once you're importing a module, the extra barrier to
templates gets smaller still.

> Feature: Ability for "field hook" user code function to only be called
> on some fields.

So the generic specifiers would change from

    [[fill]align][sign][width][.precision][type]

to

    [hook][[fill]align][sign][width][.precision][type]

where hook is some constant that won't look like a type?  (Maybe "h:")

> Changed feature: By default, not using all arguments is not an exception

I think that not using all *numeric* arguments should be an exception.
 I'll grant that the case is weaker than with normal %.

(If you really want to skip some anyhow, you can still use the "%.0s"
trick to at least make it clear that something is being skipped.)

> Feature:  Ability to insert non-printing comments in format strings

I like it.  But as with the syntax switch, I wonder if it shouldn't be
added to Templates instead.   Simply naming things gains most of the
value of comments, and beyond that ... maybe it would encourage overly
long strings.

> Feature:  Exception raised if attribute with leading underscore accessed.

Sounds good.

> Feature: Support for "center" alignment.

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

"^" may be too strongly linked with "start of line" or "not" from
regexes.  I've seen other things (usually "|") used in other contexts.
 (Of course, that has its own problems, so "^" may still be a better
choice.)

-jJ