3 ms·

So just a function that returns a closure? It can be a real pain to read code like this if it's overdone -- I really would need to trust somebody to let them go

by myaso 9y ago

So just a function that returns a closure? It can be a real pain to read code like this if it's overdone -- I really would need to trust somebody to let them go meta at their discretion.

daveFNbuck 9y ago
The key is to have powerful ones that you re-use a lot. Then most of the time you just have simpler functions with standardized annotations.
mst 9y ago
I can't see any reason you can't do something like: class MetaDec(args, here): ... def __call__(self, func): # Decorate function here def meta_dec(args, here): return MetaDec(args, here) @meta_dec def decorated: ... (apologies for any syntax fails, python is not my best language) At which point one would imagine you can abstract out the __call__ part and just have a 'decorate' routine on any class designed to work what way or similar. Whether this is an improvement or not over closures almost certainly depends on the use case, of course.
- myaso 9y ago
  Does the code actually work? Wouldn't you need to create a instance within meta_dec and return the result of the __call__ method. See at first glance I won't think it would work if I didn't know __call__ is a magic method in python. I don't think I'm being overly picky but I found the previous example much easier to read -- since it's a pattern I defaulted to myself before across several different languages. Mixing classes and FP like that doesn't resonate well with me tbh, but yeah you could do it ... but should you?
  - mst 9y ago
    > Does the code actually work? Given its reliance on '...' and the fact I'm not great at python and typed it straight into the comment ... no. No it doesn't. > Wouldn't you need to create a instance within meta_dec and return the result of the __call__ method. No, like with ES6 parameterised decorators return a function that then gets called with the thing being decorated. > See at first glance I won't think it would work if I didn't know __call__ is a magic method in python. (1) my reply was assuming the context of us both having just read the article, which has an example with __call__ (2) as I said in my original comment, you would abstract this away (and document it), I was sketching out an alternative implementation path to allow you to have an object instead of a closure since you didn't seem to be happy with closures, not offering a complete solution > Mixing classes and FP like that doesn't resonate well with me tbh, but yeah you could do it ... but should you? (3) if you don't like closures and you don't like objects, I'm not sure what other combined function+data abstraction is available in python that you wouldn't also dislike (4) I'd probably consider doing it if I had a bunch of similar decorators and found the functional approach was starting to groan at the seams - I use objects for 'parameterised bag of functions, possibly with inheritance' quite a lot for that purpose
    - myaso 9y ago
      Sorry, must of given off the wrong impression. I'm quite happy with FP in general, I'm just aware it is possible to write some pretty horrendous things. But yeah you are completely right about (4), at some point it doesn't seem like overkill anymore.
      - mst 9y ago
        I was very much trying to find an answer to your > It can be a real pain to read code like this if it's overdone wherein (4) is, when things start getting complicated, a way to end up avoiding things turning into closure soup. Also being able to selectively override things with inheritance can really help factor things out and clean things up. > at some point it doesn't seem like overkill anymore. Though I suspect "at that point, ask yourself if you're overengineering it and only if you're sure you aren't consider moving to a class" definitely applies :)

by myaso 9y ago

So just a function that returns a closure? It can be a real pain to read code like this if it's overdone -- I really would need to trust somebody to let them go meta at their discretion.

daveFNbuck 9y ago

The key is to have powerful ones that you re-use a lot. Then most of the time you just have simpler functions with standardized annotations.

mst 9y ago

I can't see any reason you can't do something like: class MetaDec(args, here): ... def __call__(self, func): # Decorate function here def meta_dec(args, here): return MetaDec(args, here) @meta_dec def decorated: ... (apologies for any syntax fails, python is not my best language) At which point one would imagine you can abstract out the __call__ part and just have a 'decorate' routine on any class designed to work what way or similar. Whether this is an improvement or not over closures almost certainly depends on the use case, of course.

myaso 9y ago
Does the code actually work? Wouldn't you need to create a instance within meta_dec and return the result of the __call__ method. See at first glance I won't think it would work if I didn't know __call__ is a magic method in python. I don't think I'm being overly picky but I found the previous example much easier to read -- since it's a pattern I defaulted to myself before across several different languages. Mixing classes and FP like that doesn't resonate well with me tbh, but yeah you could do it ... but should you?
- mst 9y ago
  > Does the code actually work? Given its reliance on '...' and the fact I'm not great at python and typed it straight into the comment ... no. No it doesn't. > Wouldn't you need to create a instance within meta_dec and return the result of the __call__ method. No, like with ES6 parameterised decorators return a function that then gets called with the thing being decorated. > See at first glance I won't think it would work if I didn't know __call__ is a magic method in python. (1) my reply was assuming the context of us both having just read the article, which has an example with __call__ (2) as I said in my original comment, you would abstract this away (and document it), I was sketching out an alternative implementation path to allow you to have an object instead of a closure since you didn't seem to be happy with closures, not offering a complete solution > Mixing classes and FP like that doesn't resonate well with me tbh, but yeah you could do it ... but should you? (3) if you don't like closures and you don't like objects, I'm not sure what other combined function+data abstraction is available in python that you wouldn't also dislike (4) I'd probably consider doing it if I had a bunch of similar decorators and found the functional approach was starting to groan at the seams - I use objects for 'parameterised bag of functions, possibly with inheritance' quite a lot for that purpose
  - myaso 9y ago
    Sorry, must of given off the wrong impression. I'm quite happy with FP in general, I'm just aware it is possible to write some pretty horrendous things. But yeah you are completely right about (4), at some point it doesn't seem like overkill anymore.
    - mst 9y ago
      I was very much trying to find an answer to your > It can be a real pain to read code like this if it's overdone wherein (4) is, when things start getting complicated, a way to end up avoiding things turning into closure soup. Also being able to selectively override things with inheritance can really help factor things out and clean things up. > at some point it doesn't seem like overkill anymore. Though I suspect "at that point, ask yourself if you're overengineering it and only if you're sure you aren't consider moving to a class" definitely applies :)