On Mon, 17 Jul 2017 at 13:28 Raymond Hettinger <raymond.hettinger at gmail.com> wrote: > > > On Jul 17, 2017, at 8:49 AM, Guido van Rossum <guido at python.org> wrote: > > > > 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.) > > 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. > > 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. > 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? 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. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170717/100903c0/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4