I must point out on the testing standpoint: http://packages.python.org/web2py_utils/test_runner.html
-- Thadeus On Sun, Aug 1, 2010 at 5:10 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > This was my response. It is awaiting moderation: > > Hello Ahmed. Nice article. > > A few comments: > web2py runs with Jython. We just consider CPython the reference > platform. There is a known bug in the Java regex library that sun > marked as wontfix that can cause occasional runaway problems with > parsing templates in Jython. It is not a web2py specific issue but I > thought I'd mention it. > > You can use unit tests with web2py. web2py it self has unit tests in > the gluon/tests folder. You can run unit tests for your apps from the > shell (as you would do in other Python frameworks) although you cannot > run them through the web IDE. The web IDE only supports doctests and > you are correct about that. > > Web2py is known to work with WingIDE, Eclipse and IntelliJ. > > It is true that web2py does not distinguishes production from > debugging mode but to clarify: this is because webp2y always in > production mode yet it always logs all the errors. If the current user > is logged in as administator he/she has access to the error tickets > and error tracebacks. > > Web2py follows PEP8 internally but it does not import application > code, executes it. In this environment it exposes some symbols. Some > symbols are per-http-request. Some symbols are system wide. The latter > are all caps because should be treated as constants and not modified. > I feel this is consistent with PEP8. The naming scheme is explained in > the first chapter of the manual. > > You are also right that web2py has a DAL, not an ORM. The main > difference is that in a ORM a table is a class and a record is an > instance of that class. In the web2py DAL the table concept is a class > but each table is an instance and each record is a dictionary. In my > view both approaches are object oriented. For example this is a query > with the web2py DAL: > > for row in db(db.mytable.myfield>0).select(): print row.myfield > > and this the same query with the Django ORM: > > for row in Mytable.objects.filter(myfield__lt=0): print row.myfield > > In my opinion the former looks more OO than the latter. >
