2. How is a string read from the terminal fundamentally different in Lisp than in Python? How is
(eval (read-from-string "(anything here)"))
different from Python's
eval('anything(here)')
? Just because it's possible to build the arguments of eval without using strings in Lisp does not mean that they are somehow less arbitrary.
3. I don't see how Python's import is different, the SBCL runtime, for example, locates and reads the source file when you import it, compiles it to native code (if a cached copy is not available), and runs it.
4. I missed the (apparently) implicit "that easily fits into GCC's present compilation model" in your earlier comment. I'm have no arguments with that statement, and indeed, I don't think GCC would be a good place to work on static compilation for Python. Rather, my argument is with a claim (intended or not) that Python is just too dynamic to ever be compiled, for which I think Lisp compilers are a living counter-example. From the sbcl man page:
SBCL compiles by default: even functions entered in the read-eval-print
loop are compiled to native code, unless the evaluator has been explicitly
turned on. (Even today, some 30 years after the MacLisp compiler, people
will tell you that Lisp is an interpreted language. Ignore them.)
We are not discussing the difference between Python and Lisp (that is merely a short detour into something I know little about).
The argument is whether we can compile Python with gcc. We cannot, because of eval(). Can Lisp compile eval()? Yes, for a different value of 'compile' and a different value of 'eval'. You argue that the values of 'eval' are the same in Lisp and Python - I honestly don't have enough knowledge to evaluate that. All I know is that if they are, then Lisp compilers are not static compilers, in which case the argument has no bearing on the discussion about python and gcc.
You have implied that you can statically compile python eval()-statements, but you have not backed that up.
Perhaps we disagree about the term "static compilation". SBCL and other lisp compilers read a source file and produce native code which is then executed. If certain dynamic features are not executed, then the compiler (also part of the runtime in much the same way as libc is part of a C executable) is not invoked at runtime. If dynamic features are needed, then the expression is eval'ed by compiling it to native code and executing it. This is lighter and more powerful (for language reasons) than spawning a process to invoke a C compiler that produces a shared library which is dlopen'd on the spot, but I claim it is a closer analogy to what is happening than a JIT.
In summary, I submit that (i) Python eval is no more dynamic than Lisp eval and (ii) it is acceptable to use the term "statically compiled" even if the standard library includes "compile".
3. I don't see how Python's import is different, the SBCL runtime, for example, locates and reads the source file when you import it, compiles it to native code (if a cached copy is not available), and runs it.
4. I missed the (apparently) implicit "that easily fits into GCC's present compilation model" in your earlier comment. I'm have no arguments with that statement, and indeed, I don't think GCC would be a good place to work on static compilation for Python. Rather, my argument is with a claim (intended or not) that Python is just too dynamic to ever be compiled, for which I think Lisp compilers are a living counter-example. From the sbcl man page: