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

Josiah Carlson jcarlson at uci.edu
Wed Mar 14 02:37:58 CET 2007

"Patrick Maupin" <pmaupin at gmail.com> wrote:

On 3/13/07, Josiah Carlson <jcarlson at uci.edu> wrote: > > 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. I think the syntax could be considered 'subtle', but I'm not really sure about how it is 'implicit' -- the rules of engagement are quite explicit. In any case, the current PEP has a % format specifier operator, so you would need a way to have % inside your %%. There may be some other issues with having the "transition to markup" and "transition back to text" characters be the same, but I can't think of them at the moment.

It's all a matter of opinion regarding the meaning of 'implicit' and 'subtle'. Going with a couple dictionary definitions of implicit and subtle on dictionary.com:

"Implied or understood though not directly expressed" "difficult to perceive or understand"

I would say that it is not uncommon for one person's implied meaning to be difficult to perceive or understand to another. That is to say, in this case, I believe implicit is subtle, or really, your use of a construct with implied meaning that is not obvious to the casual observer, makes the meaning of the construct difficult to understand.

Now, in the case of curly braces in a language like C/C++ or even Java, there was likely a secondary implied requirement, which constructs some kind of counter to keep track of the number of implied and required closing curly braces, for things like...

void foo() {
    if (bar) {
        ...
    }
}

I'm still -1. Define the words how you want, escaping should be explicit via doubling, or through the use of an alternate (but equivalent) syntax. Heck, if you feel really ambitious, consider offering explicit start/end symbols with your .flag_format() method.

> [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'.

Out of curiosity, do you feel that eval()'s use of this is somehow different? I haven't been able to figure out a real difference yet.

eval() should require explicit locals() and globals() if the user wants to use them. Not providing a locals() at least should be an error.

> > (Description of comments deleted) > > -1 > > The user can use the parser/compiler to get this behavior for free. > > (" text " #your comment here > "more text").format(...)

I think breaking up strings this way can be really ugly. (I might be alone here, but OTOH if I am, I'm not sure why triple-quoted strings were invented :) I also think there may be use cases which involve, e.g. strings read in from a separate text file. It might be handy to have comments in that other file, and it would be nice not to require a separate user-code parser to strip them out.

from other import formatx from other import doc as formatx formatx = ConfigObj.unrepr(open('formatx', 'r').read())

I'm not saying that breaking up strings as I did is pretty. What I'm saying is that you can do it now. I'll also say that inlining comments is ugly and confusing. I'd rather not have the feature than have an ugly and confusing feature.

Also, when breaking up the strings, you can exploit your editor's syntax highlighting to comment as necessary. Yes, it requires using Python's import machinery, exec, or even a mangled variant of ConfigObj.unrepr() (what I would personally suggest), but those are relatively small prices to pay to keep the syntax from being confusing.

Thanks for the feedback. For some reason, my post hasn't garnered that much attention yet. Do I need to post it on python-dev or c.l.p., or are people just really busy with other things, or have I breached some etiquette I don't yet understand?

I would guess that people are busy and/or somewhat uninterested. Personally, I'm happy with '...'%(...), and commented on this feature because (like many other features) I would much prefer Python to be pretty.

More information about the Python-3000 mailing list