"Patrick Maupin" <[EMAIL PROTECTED]> 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
_______________________________________________
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
