On 3/12/07, Patrick Maupin <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
