mirror of
https://github.com/not-kennethreitz/convore.json.git
synced 2026-06-05 23:20:19 +00:00
1 line
7.2 KiB
JSON
1 line
7.2 KiB
JSON
[{"user_id": 960, "stars": [], "topic_id": 41049, "date_created": 1309656324.0385449, "message": "Anyone got any ideas?", "group_id": 292, "id": 1550454}, {"user_id": 960, "stars": [], "topic_id": 41049, "date_created": 1309656310.128145, "message": "It seems like there should be a better way to do this: https://github.com/tswicegood/fabric/blob/task-cleanup/fabric/decorators.py#L25-33", "group_id": 292, "id": 1550453}, {"user_id": 18157, "stars": [{"date_created": 1310505317.6817219, "user_id": 37937}], "topic_id": 41049, "date_created": 1309674440.538552, "message": "I like to use http://pypi.python.org/pypi/decorator", "group_id": 292, "id": 1551090}, {"user_id": 8391, "stars": [{"date_created": 1309711488.4684651, "user_id": 960}], "topic_id": 41049, "date_created": 1309700453.6789939, "message": "@jirwin the decorator decorator is awesome. However, that doesn't answer his question :)", "group_id": 292, "id": 1552026}, {"user_id": 20326, "stars": [{"date_created": 1310015632.8862469, "user_id": 3354}], "topic_id": 41049, "date_created": 1310003953.220789, "message": "...are a bad idea. Deal with it being `@foo` (or make a utility function `bar` and use `@bar` instead of `@foo()`). It might not seem nice right now, but the consistency will make your code saner and nicer.", "group_id": 292, "id": 1581589}, {"user_id": 3354, "stars": [], "topic_id": 41049, "date_created": 1310015664.719434, "message": "@mikegraham Indeed, it's a simple and rational refactoring to use two functions.", "group_id": 292, "id": 1582380}, {"user_id": 25337, "stars": [], "topic_id": 41049, "date_created": 1310024507.7434371, "message": "I agree with @mikegraham. In fact, I always write my decorators now so they take arguments, as most of them eventually have to, later in their lives. It just took me a few goes to wrap my head around the double-wrap syntax, and the namespace/assignment gotchas.", "group_id": 292, "id": 1582825}, {"user_id": 2588, "stars": [], "topic_id": 41049, "date_created": 1310086176.542624, "message": "Here is his code, which I grabbed from the Apress site's download link (http://www.apress.com/downloadable/download/sample/sample_id/680/)", "group_id": 292, "id": 1589068}, {"user_id": 2588, "stars": [], "topic_id": 41049, "date_created": 1310086251.898885, "message": "@mikegraham @danfairs Can you elaborate on the dangers?", "group_id": 292, "id": 1589074}, {"user_id": 2588, "stars": [], "topic_id": 41049, "date_created": 1310086185.6705711, "message": "def optional_arguments_decorator(real_decorator):\n def decorator(func=None, **kwargs):\n # This is the decorator that will be\n # exposed to the rest of your program\n def decorated(func):\n # This returns the final, decorated\n # function, regardless of how it was called\n def wrapper(*a, **kw):\n return real_decorator(func, a, kw, **kwargs)\n return wrapper\n if func is None:\n # The decorator was called with arguments\n def decorator(func):\n return decorated(func)\n return decorator\n # The decorator was called without arguments\n return decorated(func)\n return decorator\n\nif __name__ == '__main__':\n def decorate(func, args, kwargs, prefix='Decorated'):\n return '%s: %s' % (prefix, func(*args, **kwargs))\n decorate = optional_arguments_decorator(decorate)\n \n def test(a, b):\n return a + b\n test = decorate(test)\n \n assert test(13, 17) == 'Decorated: 30'\n test = decorate(test, prefix='Decorated again')\n assert test(13, 17) == 'Decorated again: Decorated: 30'", "group_id": 292, "id": 1589069}, {"user_id": 2588, "stars": [{"date_created": 1310376471.521347, "user_id": 37199}, {"date_created": 1311734302.798172, "user_id": 960}], "topic_id": 41049, "date_created": 1310087077.006254, "message": "Also FWIW - the Django login_required decorator is an example (works with or without arguments) and the world hasn't ended yet :) https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator", "group_id": 292, "id": 1589131}, {"user_id": 2588, "stars": [], "topic_id": 41049, "date_created": 1310086126.048589, "message": "FWIW Marty Alchin writes about this in Chapter 2 of \"Pro Django\"", "group_id": 292, "id": 1589061}, {"user_id": 4156, "stars": [{"date_created": 1311734385.731384, "user_id": 960}], "topic_id": 41049, "date_created": 1310158105.4493599, "message": "My opinion is that is is a worthwhile tradeoff to have some (in this case, not a large amount, and not an amount that is going to increase significantly after the initial setup) complexity in-code to offer a saner API.", "group_id": 292, "id": 1595924}, {"user_id": 4156, "stars": [{"date_created": 1310230919.798738, "user_id": 8391}], "topic_id": 41049, "date_created": 1310158190.1758759, "message": "And the \"just have the decorator always take args\" approach adds ugly bare parentheses to every call -- especially if the decorator's base use case is to not have args", "group_id": 292, "id": 1595945}, {"user_id": 4156, "stars": [{"date_created": 1311734391.05672, "user_id": 960}], "topic_id": 41049, "date_created": 1310158156.9654191, "message": "The \"have two decorators\" approach adds a needless 2nd name to your API, adding confusion for users (which one do I use in which situation again? Oh crap, this wasn't the decorator that takes args, was it? etc)", "group_id": 292, "id": 1595934}, {"user_id": 4156, "stars": [{"date_created": 1310296862.140815, "user_id": 26925}], "topic_id": 41049, "date_created": 1310158224.5609629, "message": "So again, IMO, this sort of approach falls under the allowable limit for under-the-hood complexity added to have an easier to use API", "group_id": 292, "id": 1595952}, {"user_id": 20326, "stars": [], "topic_id": 41049, "date_created": 1310396794.077673, "message": "@unbracketed, It makes your code harder to write and more fragile. If your decorator receives one argument, how do you know whether it's a parameter or the callable? If you try to typecheck in some way, then this is non-idiomatic and highly error-prone. If it's impossible for you to receive exactly one positional argument for parameterization, you can do this more safely but still with non-idiomatic signature-checking/overloading-faking. Additionally, in both cases writing your decorator (and hence reading, maintaining, debugging, etc. it) is more difficult.\n\nCertainly there are some decorators in the wild that work this way, but that doesn't make them less precarious. We can find dozens of examples of APIs in Django I hope noone would hold up as idiomatic or nice.", "group_id": 292, "id": 1612795}, {"user_id": 2588, "stars": [], "topic_id": 41049, "date_created": 1310405789.3542891, "message": "Thanks for the explanation @mikegraham. Coincidentally this was discussed a bit in Armin's recent article and Nick's response.", "group_id": 292, "id": 1613746}, {"user_id": 25337, "stars": [], "topic_id": 41049, "date_created": 1310628914.4972911, "message": "@unbracketed @bitprophet I guess my problem was that my brain wasn't large enough to write a decorator that could or could not take arguments. I guess I could solve that with a decorator... :)", "group_id": 292, "id": 1635537}] |