Hacker News Reader

Comment by solipsism | Hacker News Reader

Not true. Decorators hijack your function surreptitiously. They turn y = f(x) into y = g(f, x) in a sneaky way that doesn't require you to adjust to call site. In this way it's more than "just higher order functions".

View on HN

I could turn:

    def make_money():
        blockchain_pyramid_scheme()

into:

    @with_jazz_hands
    def make_money():
        blockchain_pyramid_scheme()

or equivalently:

    def make_money(*args, **kwargs):
        with_jazz_hands(make_money_impl, *args, **kwargs)
    
    def make_money_impl():
        blockchain_pyramid_scheme()

Both ways wrap with_jazz_hands around make_money without altering the call sites of make_money.

and then suddenly, your signature goes from `f()` to `f(args,*kwargs)`, you lose all of make_money's documentation too

There's a decorator for that: https://docs.python.org/3/library/functools.html#functools.w...

You've called it sneaky and surreptitious, but I suspect in many cases it can be very useful to be able to wrap a function without performing shotgun surgery on everywhere it's called.

Of course you're right. These things are trade-offs. If it had no upside we wouldn't be talking about it because no one would use it.

No, you're strictly wrong. Decorators are less powerful higher order functions. They "hijack" the definition of your function.

Please, please learn about what higher order functions are in a more general setting before invoking them.

Uh, I know what higher order functions are. You misinterpreted my comment, I wasn't saying decorators are more powerful than higher order functions. My point was that decorators are implicit in a way standard, explicit use of higher order functions is not.

This "please, please learn" bullshit comes off as so smug and patronizing, did you realize? And when you're misunderstanding something it's even worse.

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

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

Heaven forbid we compose functions. We're only allowed to use composition on classes, where it has multiple definitions and caveats! Much less confusing.

Function composition is great. In-place mutation of a function definition is not great.

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!

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.

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?

> 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.

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.

Decorator are litterally what I said.

Litterally.

You can take any code with decorators and replace them with this syntax. If you have arguments you must call the factory first, that's the only exception.

(« Literally » n'a qu'un « t ».)

Merci.

No, they turn y = f(x) into y = g(f)(x), or rather they turn f into g(f), considering side effects.

Reply on news.ycombinator.com