On Mon, 17 Jul 2017 at 13:28 Raymond Hettinger <raymond.hettin...@gmail.com>
wrote:

>
> > On Jul 17, 2017, at 8:49 AM, Guido van Rossum <gu...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to