web2py on Quora

[Anthony]

Jacob Kaplan-Moss (Django core developer) has taken his anti-web2y show on the road from Reddit to Quora: http://www.quora.com/Is-web2py-a-good-Python-web-framework

 

I have included a response to Jacob within my own answer to that question.

 

Cheers,

Anthony

[Stefaan Himpe]

> I have included a response to Jacob within my own answer to that question.

I liked your answer.

I can't speak to wether django is a good web framework: I haven't used
it. I suspect it is though. However, his review of web2py is not a good
review at all. It is based on no experience, based on dogmas drawn from
an incomplete reading of the Zen of Python??, basically just a
collection of prejudice. Utter waste of time :( The only thing missing
is the burning of the witch, which would totally make sense given all
the "evidence" formulated against her...

It never ceases to amaze me how much effort people are willing to invest
in putting web2py down... why should they even care? (Ah! But we know
the answer to that of course: Web2Py is really *good* :-) )

[ron_m]

An interesting recent trend. I follow comp.lang.python as well and the web2py-users group recently has more traffic than the python group. That might be an indicator of the level of interest in this nice to work with framework.

[Christopher Steel]

Wow!
Congratulations ladies and gentlemen and welcome to the "big leagues".
We rock!!!

[mikech]

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.

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.

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.

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.

[Massimo Di Pierro]

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.

[pbreit]

Would there be any way to close the gap at all? I have liked working with Web2py so far but I feel like the argument above may have some merit and should not be dismissed.

[Massimo Di Pierro]

Python has 31 keywords. exec is one of them. It cannot be that
evil ;-)

It is childish to criticize web2py for the use of a keyword without
understanding the algorithm in which the keyword is used.

Web2py was audited for security and did well:

http://www.pythonsecurity.org/wiki/web2py/

In fact we do not use exec or eval with user input, only with server-
side code or code provided by the system administrator.

Since then, Django has reported major vulnerabilities:

http://www.linuxsecurity.com/content/view/154384/100/
http://www.f-secure.com/vulnerabilities/SA200905517
http://cvedetails.com/cve/CVE-2011-0698/
http://cvedetails.com/cve/CVE-2010-4534/

I am sorry to say people who spread these rumors are buying into the
propaganda and not thinking with their head. Smart people will look at
the credentials, education and professional experience of the
developers as opposed to how much they blog.

The only argument that has merit is Mitsuhiko's argument that we
should not exec code that contains classes with a __del__ method or
this will result in a memory leak. We know that and we do not do it.
It is a small price to pay for what it gives us. It is not something
that we want to get rid of.

Massimo

[Michael McGinnis]

On Mar 1, 8:34 pm, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:

>
> 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.
>
>

Everything has a default... maybe that's why web2py "just works." As
long as newbies are afraid to use Linux and Python because they think
these tools are too complex, we don't have the luxury of standing on
purity - to say, "It's more important for you to follow our technical
rules than to get your work done." If we do, nobody will dare to try
anything beyond Windows and PHP.

[Anthony]

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

[Luther Goh Lu Feng]

Wow! web2py even has a webpage at
http://pythonsecurity.tumblr.com/post/807089821/web2py-a-framework-that-cares-about-security

Anyway, I just came across this
http://www.owasp.org/index.php/Projects/OWASP_Secure_Web_Application_Framework_Manifesto/Releases/Current/Manifesto

I guess it is a read for anybody interested in web framework security


On Mar 2, 10:59 am, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:

[mikech]

Thanks for the responses.  Anthony, you're explanation is one of the clearest I've seen, and makes sense, or maybe some of these points are starting

to finally sink in.

Now if only this message would get out a bit more.  If I ever get sufficiently experienced with this, I'll present web2py at my user group.