Hacker News Reader

Comment by hacknat | Hacker News Reader

Decorators should be higher on this list. I work with Python daily and I absolutely loathe people's custom decorators that obfuscate functionality away, like STL in C++, except no type system of course.

Also, preach on duck typing it's a python myth that is absurd. If it quacks like a duck means I had to figure out what it was.

This language is slowly destroying my soul, one painful unit test at a time.

View on HN

I love decorators so much (when used well).

For example, I used a decorator the other day that I called `@logperf` that I can pin to any function, which will `logger.info` the approximate time it takes to run the whole function. It doesn't mutate what the function does, it just adds a side effect.

It doesn't take away the argument that neither decorators and with would be necessary if lambdas was a language feature.

The point isn't about the functionality of a lambda. The point is that the syntax for a decorator denotes semantic meaning that you don't get when composing a lambda on your own.

Decorators are just higher-order functions. Of all my frustrations with Python, decorators are not one of them.

Exactly, decorators are just a syntaxic sugar for foo = bar(foo). Nothing bad about it.

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

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.

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.

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

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.

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

>This language is slowly destroying my soul, one painful unit test at a time.

So we're two! I'm trying out Rust for a side project now and so far it's fun. Lots of compile-time checks, non-crippled lambdas, and you can use itertools too!

This language is slowly destroying my soul, one painful unit test at a time.

At the end of the day, Python is just an abstraction. It isn't destroying your soul, or doing anything else to it.

OTOH, your conscious decision to stick it out in a job that makes you work with a language that you find "absurd", and where people do things you "absolutely loathe" but have to put up with, anyway? That's what's destroying your soul, man.

Why do you think the STL obfuscates functionality?

Classes, objects and functions themselves all obfuscate (or rather encapsulate) functionality away in similar ways. What is so particularly bad about decorators?

I'm with you except "like STL in C++". What does that mean? STL is not custom, it's by definition standard.

Maybe you meant to say TMP?

I have seen some ridiculous templates in C++. Isn't STL Turing complete?

You're definitely talking about TMP, template metaprogramming. The STL is a set of useful libraries that do specific things. Like represent strings or vectors. Or sort, or generate random numbers. If anything the STL is too small.

TMP, on the other hand, is an entirely separate language within C++ that allows you to create monstrous, arcane code that's incredibly hard to debug or understand. Some of the STL uses TMP. But it sounds like custom TMP is the thing you don't like.

C++ template metaprogramming is Turing-complete, except that in practice your loops are going to be cut short by the maximum recursion limit of the compiler (900 in g++, see -ftemplate-depth option).

I like decorators.

I don't quite understand the author's complaint about this specific case of decorators. An initial read makes me wonder why he doesn't use dynamic routes, which is where the decorator / function-name pattern really starts to shine.

Decorators are good when used properly and functionally as in it returns the composition of two functions. In one django project one of the old coders created this decorator that adds this huge context object that automatically folds little tidbits of info from cookies and GET query params as an object stuck into an attribute that's part of the request parameter, then proceeds to use that context object everywhere. We get mysterious view functions that has lines that looks like this: request.context.start(), and will utterly fail if you removed the decorator.

Literally, please do not do this shit. Your function should be modular and able to be useable with or without being decorated.

That honestly sounds like a very poorly written decorator to me. I work with Django professionally and have been for years now. I'm not going to say I know the framework like the back of my hand, but I'm pretty damn close. Django already supplies the request object to every single view regardless of whether or not the view is class or function based. Why you would need a decorator to replicate existing functionality is beyond me. It's possible that the decorator was created for an older version of Django that was missing some important part of the request object, but I can't for the life of me figure out what that would be.

Reply on news.ycombinator.com