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

[Patrick Maupin]

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
>