In web.py you define all your routes in an array, as the first argument to the web.application method. Each route also gets an associated class. In Bottle, each route is defined by a function decorator and is associated with a function. You could see that by comparing the front pages of both web sites.
mitsuhiko2 points · Mar 2010 · :flask-logo: Flask Creator
The downside of the decorators is, that you have to import all the views before the server runs for the registration to kick in. The advantage is that the URL rule is closer to the function.
FTR, I wrote a relatively simple library that makes choosing between locality of reference and import-time-side-effects-required a little less painful: http://docs.repoze.org/venusian/
The bottle.route() decorator returns the callback function unchanged. It stores a reference to the function object, but neither wraps nor manipulates it. Venusian still is an interesting tool, thanks for the link.
Yeah, besides testability, the docs should probably concentrate equally on the fact that you can get locality of reference without requiring that all participating modules be imported by the user. Thanks.
While I don't think your library addresses mitushko's downside, I appreciate the clarity with which you have explained why non-mutating decorators are desirable. OTOH I don't see the startup cost of a bunch of imports as significant (especially vs failing fast), and decorators like this can be used as functions in one location if you want to build up routes in one place, so it's win-win-win!
The downside he expressed was "you have to import all the views before the server runs for the registration to kick in". I think venusian does address this.
If you use something like venusian, the user doesn't need to remember to import every module that potentially has decorated objects in it; he just needs to run a scan against a package, and venusian will find all the decorated objects in the package and all subpackages.
In bottle, you can add new routes at any time, even from within a callback while the server is running. If you want to define your callbacks first and add the routes later, you can use the decorator as a normal function:
mitsuhiko2 points · Mar 2010 · :flask-logo: Flask Creator
Obviously that will work. However, that is completely irrelevant to the discussion decorator or explicit mapping. One can easily be converted to the other.
how does is compare with web.py?
beam 3 points · Mar 2010
In web.py you define all your routes in an array, as the first argument to the web.application method. Each route also gets an associated class. In Bottle, each route is defined by a function decorator and is associated with a function. You could see that by comparing the front pages of both web sites.
xamdam 1 points · Mar 2010
Thanks. I guess I was wondering what the advantage or specialization is
mitsuhiko 2 points · Mar 2010 · :flask-logo: Flask Creator
The downside of the decorators is, that you have to import all the views before the server runs for the registration to kick in. The advantage is that the URL rule is closer to the function.
mcdonc 3 points · Mar 2010
FTR, I wrote a relatively simple library that makes choosing between locality of reference and import-time-side-effects-required a little less painful: http://docs.repoze.org/venusian/
defnull 2 points · Mar 2010 · bottle.py
The bottle.route() decorator returns the callback function unchanged. It stores a reference to the function object, but neither wraps nor manipulates it. Venusian still is an interesting tool, thanks for the link.
mcdonc 1 points · Mar 2010
Yeah, besides testability, the docs should probably concentrate equally on the fact that you can get locality of reference without requiring that all participating modules be imported by the user. Thanks.
grayvedigga 1 points · Mar 2010
While I don't think your library addresses mitushko's downside, I appreciate the clarity with which you have explained why non-mutating decorators are desirable. OTOH I don't see the startup cost of a bunch of imports as significant (especially vs failing fast), and decorators like this can be used as functions in one location if you want to build up routes in one place, so it's win-win-win!
mcdonc 2 points · Mar 2010
The downside he expressed was "you have to import all the views before the server runs for the registration to kick in". I think venusian does address this.
If you use something like venusian, the user doesn't need to remember to import every module that potentially has decorated objects in it; he just needs to run a scan against a package, and venusian will find all the decorated objects in the package and all subpackages.
grayvedigga 1 points · Mar 2010
Oh, I see now -- I totally missed the point. Excellent feature, and thanks for clarifying a source of bugs I totally haven't been anticipating.
defnull 1 points · Mar 2010 · bottle.py
In bottle, you can add new routes at any time, even from within a callback while the server is running. If you want to define your callbacks first and add the routes later, you can use the decorator as a normal function:
It is possible to simulate the web.py or django behavior (routes stored in a list) with import and a simple a for-loop, if you really want that.
mitsuhiko 2 points · Mar 2010 · :flask-logo: Flask Creator
Obviously that will work. However, that is completely irrelevant to the discussion decorator or explicit mapping. One can easily be converted to the other.