I believe this is why web2py receives much criticism. I speak from experience in using (and contributing to) web2py.
web2py cannot share objects in an importable namespace with other python applications ecause of its design architecture. This is an absolute requirement for most "enterprise" or "real world" applications. Two examples. (however there are many more than I have time to iterate over) Exhibit A: Multiple websites that share some or all database models and utility functions. A public site may use only some of the models needed for say user signup, and a dashboard that may be IP restricted for internal use only. Exhibit B: Must share database models with stand alone python programs. A long running process that sits in the background, but needs access to the database. web2py cannot do either of these, and unless web2py uses import it will never be able to. Currently, to accomplish exhibit A or B, code spaghetti-fication must occur, and maintainance of model definitions in multiple places now becomes a royal pain in the ass. That or you must use some of the other many (unprofessional, hard to maintain) hacks just to work around this limitation. With other frameworks, such as flask/sqlalchemy it is a python program like anything else. You can do "from dashboard.models import person". You only maintain one model, but you can use it in all applications that may need it, since you can easy_install your site into a virtualenv. Another issue that I have ran into more often than not is the limitations in the web2py core. Certain things (like SQLForm, auth, sessions, etc) are great for rapid prototyping, but when you actually need to do something "real" with them, they just get in the way. For example, a form that has a subform or a built in subtable (like a form you might build in Access), or cookie stored sessions for scalability. Again, these are just simple examples when the real world implementation is much more complex. Another problem that the current design of web2py inherently brings is it enforces a functional programming style. You can use classes, but then you end up having to throw pointers around of your basic objects (db, session, etc). Using classes the way they are designed to be used with a normal object lifecycle (imported, instantiated, etc...) is extemely difficult to do in web2py. There is nothing wrong with functional programming, but the code can easily become a mess even if you are a good programmer. Just to give an example of how amazing a class based system is, I re-wrote appadmin for Flask+SQLAlchemy+WTForms in 80 lines of python code, with pagination, searching, creating, updating, and deleting. Think of how maintainable that is. I don't even know what is going on inside of web2pys appadmin... I try to stay away from it *wink*. One of the biggest arguments vs other frameworks is the speed of development time of a web2py app vs other framework. I disagree with this, I am usually able to add new features to my flask apps much faster than I can in web2py. This is probably due to the simplicity of other frameworks and not having to fight with anything being pre-determined for me (such as database tables forced to lowercase). As long as all your doing is building a simple website that will be completely 100% self contained into web2py and it isn't expected to grow over 10K lines of python code, web2py is great. If you are doing something that requires code to be shared, and has lots of complex models and a large codebase that will need to be maintained by other people than yourself in the future... I would pick Flask. I speak most of this from real world experience. I work in both web2py and flask every single day and know the strengths and weaknesses of both. I just wanted to take the time to chime in as to why some feel they way they do with web2py... maybe they just don't know how to explain it, or don't want to take the time to explain it. -- Thadeus On Sat, Jan 8, 2011 at 8:34 AM, Anthony <abasta...@gmail.com> wrote: > On Saturday, January 8, 2011 9:12:55 AM UTC-5, Anthony wrote: > >> +1 >> >> On Saturday, January 8, 2011 7:31:38 AM UTC-5, cjrh wrote: >> >>> On Jan 7, 11:45 pm, Michele Comitini <miche...@gmail.com> >>> wrote: >>> > I think the most misunderstood fact with web2py is that web2py >>> > implementation is improving every day, >>> >>> Do you really think the designers of other web frameworks do not >>> understand how web2py works? They definitely understand, and they >>> probably understand better than you or I. The problem is that web2py >>> design is different from their own design. Because we operate in the >>> same space, they try to show why their decisions are better. To be >>> fair, Massimo has been doing exactly the same thing by comparing w2py >>> versus the others for years. Quid pro quo. If we get to say why ours >>> is better, then they get to do likewise. >>> >> >> Good point, though it's not exactly the same. Massimo may claim that the >> web2py way is better (actually, he doesn't really make that strong claim -- >> rather, I think he would claim that there are trade-offs in design and that >> he and many others prefer the trade-offs web2py has made while still >> respecting that others may prefer different trade-offs). But I don't think >> I've seen Massimo claim that the design decisions of frameworks like Django >> and Flask are actually bad or harmful. In fact, he usually has quite >> positive things to say about other frameworks. The guys on reddit, on the >> other hand, are claiming that web2py's design decisions are outside the >> bounds of acceptability (at least within the Python world) and therefore >> merit either correction or ostracism (in fact, Jacob is not the first guy >> I've seen try to expunge web2py from the community by claiming it's not >> really a "Python" framework and doesn't use "real" Python). Basically, >> Massimo is saying Django, Flask, etc. are all good frameworks that you'll >> probably be happy with, but web2py is even better, and you should give it a >> try. The other guys are saying Django, Flask, etc. are the only "real" >> Python frameworks, and web2py is harmful (technically, and to the community) >> and to be avoided at all costs (until it completely changes its fundamental >> design distinctives and does things the way they do). >> >> Cheers. >> >> Anthony >> > > Also, you are right that many of the web2py detractors do probably > understand at least at a high level "how web2py works," but I've been very > surprised at how frequently these supposed experts exhibit complete > misconceptions about web2py. Most of them have never used web2py to build a > real application, and many of them have probably never even downloaded it > and played with it (or read the docs, or looked at the source code). I am by > no means an expert and am relatively new to both Python and web2py, and yet > I routinely spot (and point out) very basic errors these guys make in their > understanding of web2py. If they can't be bothered to comprehend the very > basic things that even I know, their opinions about web2py really can't be > taken seriously. The problem isn't that they don't know web2py, it's that > they're willing to make such bold proclamations about it despite their > ignorance and lack of experience with it. The fact that web2py has been > around for several years and has a growing, active, and highly satisfied > user base provides them no clue that perhaps their hypothetical concerns > don't play out in reality. > > Anthony >
