5 ms·

So if I do "f = g(f); y = f(x)" then it's suddenly not decorator?

by joesb 9y ago

lmm 9y ago
Doing it that way at least means your code looks exactly as bad as it is.
- KirinDave 9y ago
  Heaven forbid we compose functions. We're only allowed to use composition on classes, where it has multiple definitions and caveats! Much less confusing.
  - lmm 9y ago
    Function composition is great. In-place mutation of a function definition is not great.
    - KirinDave 9y ago
      It's not mutation if it occurs before anyone can ever reference it. Then it's called construction. Even languages with labeled effects allow for this sort of construction effect. If they can properly sequence and isolate it, they allow mutation as well!
      - lmm 9y ago
        a = f(b) is fine - it's clear to the reader that a might or might not end up having anything to do with b. @f a = b is not at all clear as a syntax for the same thing - a reader would very much expect a to = b after execution of a line like that.
        KirinDave 9y ago
        I'm a bit confused. Is @f a = b valid Python syntax? What's it implying? Why would it be a mutation? Is it because of a call-by-name convention you're implying, or because function metaprogramming in Python has write as well as read for properties? If you dislike call-by-name, why is Python's practice of insisting all non-trivial functions be called by name is not distasteful to you?
        lmm 9y ago
        > Is @f a = b valid Python syntax? No, I was trying to isolate the important part. "@f def a: return b" would be the Python syntax, and I think it's misleading as sugar for, hmm, you'd have to write it as "a = f(lambda: b)" (hmm, I'd forgotten how different defining a function "natively" or as a lambda value are in Python). You seem to be using a different definition of call-by-name to the one I'm used to. What bothers me is that a decorator can make a function behave completely differently (e.g. its body might never even be executed) but the syntax doesn't look like it can make that big a change to the function.
        KirinDave 9y ago
        I think that's a fair concern, although the semantics of the decorator probably make that what you want in some points. I guess in Python land, blueprint's entire purpose is to selectively fire your handlers.

So if I do "f = g(f); y = f(x)" then it's suddenly not decorator?

by joesb 9y ago

So if I do "f = g(f); y = f(x)" then it's suddenly not decorator?

lmm 9y ago

Doing it that way at least means your code looks exactly as bad as it is.

KirinDave 9y ago
Heaven forbid we compose functions. We're only allowed to use composition on classes, where it has multiple definitions and caveats! Much less confusing.
- lmm 9y ago
  Function composition is great. In-place mutation of a function definition is not great.
  - KirinDave 9y ago
    It's not mutation if it occurs before anyone can ever reference it. Then it's called construction. Even languages with labeled effects allow for this sort of construction effect. If they can properly sequence and isolate it, they allow mutation as well!
    - lmm 9y ago
      a = f(b) is fine - it's clear to the reader that a might or might not end up having anything to do with b. @f a = b is not at all clear as a syntax for the same thing - a reader would very much expect a to = b after execution of a line like that.
      - KirinDave 9y ago
        I'm a bit confused. Is @f a = b valid Python syntax? What's it implying? Why would it be a mutation? Is it because of a call-by-name convention you're implying, or because function metaprogramming in Python has write as well as read for properties? If you dislike call-by-name, why is Python's practice of insisting all non-trivial functions be called by name is not distasteful to you?
        lmm 9y ago
        > Is @f a = b valid Python syntax? No, I was trying to isolate the important part. "@f def a: return b" would be the Python syntax, and I think it's misleading as sugar for, hmm, you'd have to write it as "a = f(lambda: b)" (hmm, I'd forgotten how different defining a function "natively" or as a lambda value are in Python). You seem to be using a different definition of call-by-name to the one I'm used to. What bothers me is that a decorator can make a function behave completely differently (e.g. its body might never even be executed) but the syntax doesn't look like it can make that big a change to the function.
        KirinDave 9y ago
        I think that's a fair concern, although the semantics of the decorator probably make that what you want in some points. I guess in Python land, blueprint's entire purpose is to selectively fire your handlers.