On Mar 1, 8:11 pm, mikech <mp.ch...@gmail.com> wrote: > I was communicating with my local Python User group, and got an opinion from > one of the members a lot like this. Unfortunately I don't have the > experience to answer effectively. Here is the response that I got: > > I don't really have time to get into an epic religious discussion but > I'll try and sum it up nicely: > > 1. Think of exec/eval tools as weird magic best left alone. Regardless > of the complicated arguments, the truth is that simply debugging code > in an exec/eval argument is much harder. It means your variables are > stored in variables of variables. Web framework building is hard > enough without tossing in that sort of complexity.
Python is an interpreted language. importing a module or executing a module is the same thing. The only difference is that by importing a module data can only get out of the module. By executing the module we can pass data to the environment in which the module ie executed. Many web frameworks execute templates. Some do it using exec. Some do it using a custom designed parser. Web2py does it also for models and controllers. Philosophically there is not a big difference. It is true that, in general, exec makes things harder to debug. In the case of web2py it makes it easier because we catch the exception in the exec with tickets. > 2. I'm no security expert, but I do know that security experts always > raise the flag on Security-by-JavaScript (cough... facebook... > cough...) and exec/eval statements. If your code ever gets audited by > someone competent and they see exec/eval statements in your underlying > framework they are going to go postal. True. The caveat is that we are not exec-uting or eval-uating user's data. We are executing the code that comprises the application. Django and Flask too execute the application code (that is what a framework does), they just use import instead of exec. Criticizing a software because it uses a language keyword without understand the context in which that keyword is utilized is childish. If that keyword is so bad why Python has it? Turns out it is the only keyword that truly distinguishes interpreted languages from compiled ones and they only true reason to use Python (other that the syntax). Many python modules use exec including pdb, profile, cgi, doctest, hashlib, importutil, socket and trace. Many third party modules also do so. > 3. SQLAlchemy, libcloud, psychopg, flask, Pyramid, Django, Zope, > pygame, scipy, and 99% of the Python world does things as explicitly > as possible. They don't do extra imports for you in their controllers > or modules, which seems like extra work in the short term. In the long > run, you know EXACTLY what is going on in a file - and that counts for > so much. That is a difference. They follow "explicit is better than implicit" and that cause verbosity. We choose to follow "do not repeat yourself" and "everything should have a default" so web2py's code is more compact. If you like this you use. > 4. JKM's major rant on reddit was that this behavior defined in point > #1 above makes Web2py different than the rest of the Python world. And > that they are training a breed of new python developers who expect > different behavior in code then the rest of us. Call me a fanboy (and > employee), but he's right. If you have a problem with Web2py the > majority of the people on this list or any python list will be > crippled in their ability to help you. On the other hand, any of us > can figure out the individual components of flask, sql alchemy and > more because it is following the common pattern. So that means while I > may not know much about SQLAlchemy, I can figure out what's going on > inside. He continues to misinform people about the role of the exec and gives the impression web2py does not work well with others. That is simply not true. Most of the web2py modules can be used independently of web2py (for example the dal, the template language, the syntax highlighter) and any python module can be used in web2py without restrictions.
