3 ms·
Kudos again to the pocoo team for creating such a simple and useful library. It sure beats optparse :) On a side note, however, does anyone know why the team p
by pandatigox 13y ago
Kudos again to the pocoo team for creating such a simple and useful library. It sure beats optparse :)
On a side note, however, does anyone know why the team prefers to wrap functions in decorators? Flask also uses them, but what's the design decision behind them?
- hoodoof 13y agoDecorators are so simple and minimalistic and elegant and easy to understand. They can surface an arbitrary amount of extra functionality with a single statement. For example, ensure a function is only accessible to authenticated users by simply saying something like @requires_authenticated_user. Another example would be to create a logging decorator to wrap a function or a class to create a log of every time the function is accessed @log_function_access. Or to wrap a function to ensure that every access to the properties of that function are pushed through some sort of validation or transformation @validate_set or @transform_get. Decorators allow encapsulation of functions within other functional concepts with almost no code, that's the design decision for using them.
- HeyImAlex 13y agoYep, it's best us case is basically acting as pythons anonymous function (since lambdas suck for everything but the most trivial things). Where in js flask might read app.route('/', function(){//do something}); python uses a decorator right above a regular function definition. The alternative is to manually add it after it's defined (in flask that's add_url_rule), but that kind of hides the intent of the function and is more cumbersome as you need to manually pass in the fn name.
- gbog 13y agoThis is a valid question. When things become complex I found that decorator is a bit too magic, and should be used with moderation.