On 3/14/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> I think the difference is that when you see eval()
> you know something dangerous is going on, but most
> uses of format() would be harmless -- *except* when
> given no arguments. It would be an easy thing to
> overlook when reading code.
>
> If this functionality is to be provided, I think
> it should at least have a different method name
> to make it stand out more clearly.
That might be a reasonable difference. I can think of two possible
counterarguments: 1) if there is always "something dangerous" going
on with eval(), making it harder to write eval(), and making the user
think about which set of variables he really wants to pass in might
not be such a bad thing, either; and 2) the actual percentage of use
cases of ''.format() where "something dangerous" is going on, e.g.
where the programmer has passed a string that he has accepted at face
value from J. Random User, is, realistically, going to be vanishingly
small. (In most cases, .format will probably immediately follow a
literal string.)
Ian Bicking actually suggested 'somestring'.eval() for this
functionality. I like that a lot, in the sense that it gives the same
sense of danger as eval('somestring'), but at the same time, I dislike
it intensely because eval('somestring') and 'somestring'.eval() appear
so similar but would give such drastically different results.
If the default usage of locals() / globals() is really that
objectionable, we can certainly take it out. In that case, I would
suggest that one possible thing to do is:
1) Make calling format() with no variables raise an exception; and
2) Monitor the usage and see how often people do
'somestring'.format(namespace=locals()) or
'somestring'.format(namespace=(locals(), globals))
If the number of times this extra boilerplate appears in code seems
excessive, then we could either add another method to do the automatic
locals() and globals(), or (since we would know there are no uses of
format() with no variables in the code) reenable the functionality.
Regards,
Pat
_______________________________________________
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
