On Tuesday, March 1, 2011 9:11:58 PM UTC-5, mikech 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. > > The problem with these kinds of arguments is that they ignore real-world data in favor of hypotheticals and intuition. The fact is, web2py has been in use by many people for over three years, and it works very well. I suppose it's possible that exec makes it marginally harder to debug in some circumstances, but it's clearly not the nightmare this guy is making it out to be. There are better and worse ways to use exec. Just because some systems use it poorly does not mean web2py does. For example, it's important to exec code in a new environment rather than in the current scope -- and that is exactly what web2py does. Keep in mind that design decisions involve trade-offs. Perhaps exec does end up requiring a bit more debugging. On the other hand, requiring developers to do more things explicitly leaves more room for error and therefore may require more debugging as well. As long as the productivity gains from using exec outweigh any costs, it's worth it.
> 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. > > If your code gets audited by someone competent, they will not go postal because exec is only a security risk if it executes user input, which web2py does not do (the framework executes application code -- applications do not execute user input). Some people simply learn "exec is bad for security" without understanding why, so they end up over-generalizing. > 3. SQLAlchemy, libcloud, psychopg, flask, Pyramid, Django, Zope, > pygame, scipy, and 99% of the Python world does things as explicitly > as possible. > > No program "does things as explicitly as possible." It would be more explicit to copy and paste the code from another module rather than import it, but we don't do that because the gains in productivity from importing outweigh the loss of explicitness. It would be even more explicit to use a lower level language and do your own memory management, etc., but again, the gains from using a language like Python are worth it. All code is an abstraction and involves something going on under the hood that is not completely explicit in the code itself. It's not a matter of being explicit or not -- it's just a matter of degree -- and in the scheme of things, web2py is not dramatically different in degree. > 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. > > This is an overstatement. web2py includes a relatively small number of global objects -- about a dozen core framework objects that are well documented and used constantly, plus HTML helpers (which all derive from the same class and have the same names as their HTML counterparts) and validators (which all derive from the same class and most of which start with "IS_"). Everything else is explicitly imported, even other parts of the framework itself, such as mail, auth, crud, services, plugins, and contributed libraries. In web2py, it's generally very easy to know what is going on in a file, even though a few core objects are not explicitly imported. I think he's also overstating the helpfulness of imports with regard to explictness. A one line import statement doesn't tell you a whole lot about the details of the code you have imported. If you want to know anything about object methods and attributes, function signatures, etc., you still have to track down the code and figure it out. Tracking things down in web2py is not much harder. In fact, for those who prefer the additional explicitness of import statements, it's simple enough to just write some dummy import statements (e.g., inside a module docstring or an 'if 0:' block). > 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. > > The problem is, there's just no evidence that this is true. web2py does in fact use imports, so any web2py user should understand imports just fine and not "expect different behavior in code." > 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. > > First, if you have a problem with web2py, the web2py community will always be your best source of help -- and it is very helpful. But that's equally true of any framework or library. The fact is, if you have a problem with Flask or SQLAlchemy, the only people who are realistically going to help you are those who already know Flask or SQLAlchemy. In any case, web2py is very easy to learn, so if someone is inclined to help you with a framework they don't know, they should be able to help you with web2py just as easily as any other framework (probably more so). Best, Anthony
