> There is no need to hijack other frameworks'  threads.

For the record. Our thread was hijacked by both Flask and Django.

http://www.reddit.com/r/programming/comments/g875i/building_a_minimalist_facebook_clone_and/c1lnyu8
http://www.reddit.com/r/programming/comments/g875i/building_a_minimalist_facebook_clone_and/c1lqq


In the last year - as far as I remember - I only intervened in threads
about general discussion on web frameworks OR to clarify incorrect
statements made by somebody else about web2py OR after at least two
other frameworks were already mentioned and it turned into a
discussions about web frameworks.

The most recent attack came from an anonymous user who never posted
anything else but negative comments on web2py. I find it odd.

Anyway typical issues people bring up are:

# exec
we do it for a reason: in fact, we are the only framework to allow hot
install, and uninstall of apps in production and without having
sys.path conflict between modules of different apps. the way it is
done does not pose any security risk: we do not exec users'input, only
serverside code. Other frameworks do module reloading. That only works
with Python web servers. That has problems like potential memory leaks
(if imported module instantiates an object with a __del__ method and a
self reference).

# implicit imports
Rails does it too, and it is considered good. Enthought python does it
too and it is considered a flagship product by the python community.

# models and controllers are not python modules
No, they are not. Templates are not python modules in any framework,
why should models and controllers be? They are not Ruby modules in
Rails. That is because they also require a context to run: the http
request.

# web2py is a Domain Specific Language
If it were, there would be nothing bad. Yet, it is not. We use pure
Python language everywhere as opposed to other frameworks who indeed
use a domain specific language (not python) for configuration files
and yet another for templates.

# we by-pass normal imports
No. we have implicit imports (as mentioned above) and they are well
documented. web2py supports normal imports as any other python
program. We also have an additional method called local_import as a
convenience shortcut to avoid problems with the fact that sys.path is
not thread safe.

# web2py is not packaged as other web framework
True. We will change that. Yet the current packaging is particularly
convenient to new users. Some assume that because we ship all modules
together, those modules do not work independently outside web2py but,
in fact, they do.

# web2py is not perfect
True. Nothing is. It may not be for everybody. If it is not for you do
not use but do not complain about the people who made it available to
you for free.

# we attack other frameworks
Never. At most we pointed out that some of them do not seem to take
usability for new users at heart and we think that is important. Being
easy to use means lower development and maintenance costs. I also
think that some of them do a veyr poor job at backward compatibility
but I do not think I ever pointed that out outside this list.

Massimo

Reply via email to