EIBTI, it's true, but in some cases it's awfully handy to be implicit. Ian Bicking and I were tossing this around, and came up with some ideas, all of which are certainly flawed in one way or another :)
One idea is that an additional string formatting method which will automatically work with locals() and globals() could be named something like "eval". On first glance, this seems like a bad name because of the builtin eval() function, but perhaps it would be a good thing. People are warned off using eval() on strings they didn't generate, and the same should be true of a string eval() method, for the same reasons. (Or as a few of us have noted: "eval" == "evil") In any case, the initial C implementation of PEP 3101 automagically does this if format() has no parameters, but that is easy enough to rip out. Regards, Pat On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 3/6/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > > While we're at it: I've had a thought about string formatting in Py3k. > > Suppose you do something like > > > > name = "He" > > what = "Ex-Parrot" > > print "{name} is an {what}".format(name=name, what=what) > > > > it seems a bit too verbose. Why not have format() without any arguments > > default to format(**locals())? > > > > This would give those Perl-style interpolation supporters something they > > can live with, and it would be quite handy for common usage. > > I think that's a little too terse. **locals() sounds just right to me; EIBTI. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > 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/pmaupin%40gmail.com > _______________________________________________ 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