That makes me think - would it be possible to have a runtime or build time option for cpython that removes eval() ?

Probably. But python missed their chance to nix it with the 2->3 transition.

My favorite case was when a newbie coder used eval() to evaluate something that looked json-ish, which, came from an api request.

Simple and powerful. Gotta love it (until your customer doesn't, big-time).

If you run a security linter like ‘bandit’ you’ll get warnings for eval and other security holes.

It seems you can’t run bandit on deps, but perhaps if you fork them and build yourself?

If you are security conscious, having a rule that you can only install from a local pypi with packages you have forked would be a more defensible perimeter. But, a maintenance pain for sure.

but python is not the only language to have an eval(), so why is python's in particular the root of all evil?

It's not literal.

that doesn't make much sense and there are necessary uses for eval() /exec(), mostly for dynamic creation of code:

For example here's Python dataclasses in the standard library using exec() to create the `__init__` and other methods that go on your dataclass:

https://github.com/python/cpython/blob/main/Lib/dataclasses....

Here's Pydantic using it for a jupyter notebook check:

https://github.com/pydantic/pydantic/blob/594effa279668bd955...

here's Pytest using it to rewrite modules so that functions like assert etc. are instrumented by pytest:

https://github.com/pytest-dev/pytest/blob/eca93db05b6c5ec101...

Here's the decorator module using it (as is the only way to do this in Python) to create a signature matching decorator for an arbitrary function:

https://github.com/micheles/decorator/blob/ad013a2c1ad796996...

All of these libraries are completely secure as eval/exec are used with code fragments that are generated by the libraries, not based on untrusted input.

eval() /exec() are not running executable files, just Python code, the same way all the rest of the package is already doing.

Right, and each one of those is a potential exploit waiting to happen.

please support your assertion. I would also recommend opening CVEs detailing your discovered attack vectors, especially that of Python dataclasses in the standard library, which are in very widespread use. If you do in fact have some insight on how Python dataclasses are an "exploit waiting to happen", I think it's irresponsible to just sit on that information.