On Wed, Mar 5, 2014 at 3:43 AM, Steven D'Aprano firstname.lastname@example.org wrote:
That is, what's really the point of having
a = $(expr) # or `expr`, or `(expr), or c"expr"
If it's simply a slightly shorter way of spelling:
a = compile(expr, "<string>", "eval")
You can't write it like that. You have to wrap the expression is quotes and turn it into a string:
a = compile("expr", "<string>", "eval")
True, I misspelled my example. Or maybe my 'expr' implicitly meant string_expr :-). But the basic point that the literal for a "thunk" is already essentially available with compile() remains.
which means you lose syntax highlighting. Perhaps the ability to get syntax highlighting is not sufficient to justify this idea.
There's no reason you even NEED to lose syntax highlighting. A code editor could perfectly well have a highlight rule that strings inside compile() calls get highlighted. Sure, that's a pretty special language mode, but there's nothing that an editor couldn't do in principle.
Another disadvantage: the ever-present temptation to pass a user-generated string to compile:
a = compile(template % some_string, "<string>", "eval")
If some_string came from an untrusted source, you are now the proud owner of a brand new code injection vulnerability. But with syntax, you cannot generate a thunk/macro except from code you write yourself. It's still code written by you, it's just that evaluation is delayed.
The literal hardly saves you from injection attacks. I could write this too under the proposed idea:
foo = get_string_from_attacker() a = $(foo) b = a.eval()
Now one can say "don't do that!" ... but that advice applies just as well to 'compile(unsafe_string, ...)'