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

[Josiah Carlson]

"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} 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.

 - Josiah