3 ms·
Give up (at least temporarily) everything listed - eval(), locals(), REPL etc and it still is going to be extremely useful for, arguably, most of the real use c
by qwerty456127 6y ago
Give up (at least temporarily) everything listed - eval(), locals(), REPL etc and it still is going to be extremely useful for, arguably, most of the real use cases. E.g. I personally haven't ever needed any of these. REPL happens to be handy occasionally to quick-check something but I can hardly imagine it being used in production, it only seems useful in development time and for education. eval() seems a big red flag everybody should avoid at all cost.
Please do your best to support all the latest syntax though. Lack of support for some standard functions particularly hard to implement is Ok, lack of support for syntactic elements (e.g. type hints) is worse and, usually, easier to fix.
- ericvsmith 6y agonamedtuple and dataclasses both use eval(), so if you want to give up eval(), you'd need to give them up, too.
- VectorLock 6y agoInteresting they use eval(), I wonder if their implementations could be changed to not use eval(). I guess in the end you could just use actual classes for these cases, but I sure do like namedtuple and dataclasses.
- ericvsmith 6y agoMy bad: it's exec(), not eval(). And I wrote dataclasses, so you'd think I'd know better! The issue is that it's dynamically generating methods. There has to be a way to get dynamically created code into python for this use case.
- VectorLock 6y agoREPL-centric development is something that has caught on a lot lately and is something that I find myself gravitating towards more and more. For 'production' the eval() might be able to be cast off, but for development the REPL is indispensable - if not a first class requirement.
- qwerty456127 6y agoSure, but you can develop on a local instance before compiling to WebAssembly for production.