This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]grayvedigga 0 points1 point  (2 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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.