<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 17 Jul 2017 at 13:28 Raymond Hettinger <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Jul 17, 2017, at 8:49 AM, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
><br>
> One of the reasons to be wary of exec()/eval() other than the usual security concerns is that in some Python implementations they have a high overhead to initialize the parser and compiler. (Even in CPython it's not that fast.)<br>
<br>
BTW, if getting rid of the template/exec pair is a goal, Joe Jevnik proposed a patch a couple of years ago the completely reimplemented namedtuple() in C.   The patch was somewhat complex and hard to semantic equivalence, but we could resurrect it and clean it up.   That way, we could like the existing namedtuple() code in-place and do a subsequent import from the C-version.<br>
<br>
This path won't be fun (whenever we have both a C version and Python version, we get years of trying to sync-up tiny differences); however, it will give you take fastest startup times, the fastest lookups at runtime, and eliminate use of exec.<br></blockquote><br></div><div class="gmail_quote">I vaguely remember some years ago someone proposing a patch that used metaclasses to avoid using exec() (I think it was to benefit PyPy or one of the JIT-backed interpreters). Would that work to remove the need for exec() while keeping the code in pure Python?<br><br></div><div class="gmail_quote">As for removing exec() as a goal, I'll back up Christian's point and the one Steve made at the language summit that removing the use of exec() from the critical path in Python is a laudable goal from a security perspective.<br><br></div><div class="gmail_quote">-Brett<br></div></div>