[Python-3000] locals(), closures, and IronPython... (original) (raw)

Patrick Maupin pmaupin at gmail.com
Tue Mar 6 21:20:06 CET 2007

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 <guido at python.org> wrote:

On 3/6/07, Georg Brandl <g.brandl at gmx.net> 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 at python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/pmaupin%40gmail.com

More information about the Python-3000 mailing list