Curious about decorator syntax

[rjdegraff42]

I think the question is what is clearer

class A:
 
    @getter
    def foo(self):
        return 10
 
    @setter    
    def foo(self, value):
        print('Hello there!')

class A:
 
    @getter
    def foo(self):
        return 10
 
    @foo.setter    
    def foo(self, value):
        print('Hello there!')

or

class A:
 
    def foo(self):
        return 10
    foo = getter(foo)
   
    def foo(self, value):
        print('Hello there!')
    foo = setter(foo)
 

I maintain that using @getter and @setter is clearer and less prone to errors since you only specify the method name one in the def statement. Especially since case 2 allows you to specify different names in the decorator and def lines. As a side note to consider, I have a very affectionate cat so typos are frequent.

I could make the case that it makes as much sense to standardize on

@foo.getter
@foo.setter

as it does on

@getter
@setter

Except of course with the first format you still have the typo problem (which was the justification for the += operator).

[Gribouillis]

I think the question is what is clearer

This is not the question unfortunately. I can only suggest you to actually implement it if you are really motivated by this, but it won't be that easy.

A more realistic approach is to take your time. Once you'll have more experience with Python you will have more insight about the implications of such changes.

[rjdegraff42]

The point of making code pretty is to make it more readable. Likewise, making code more concise while maintaining readability is desirable.

Two pieces of code can be equivalent (no difference at all in what they do) while one is readable and the other not. Clarity is part of the Zen of Python. Consistency in coding is why we bother to have a recommended coding style.

I did not define functions named getter(), setter(), and deleter(). What I proposed was three decorators, @getter, @setter, and @deleter (technically I suggested only the first two as I was not aware of deleter).

Of the following four forms:

# version 1
class A:

    @getter
    def foo(self):
        return 'getter'
        
    @setter
    def foo(self, value):
        print('setter', value)
        
    @deleter
    def foo(self):
        print('deleter')

# version 2
class A:

    @property
    def foo(self):
        return 'getter'
        
    @foo.setter
    def foo(self, value):
        print('setter', value)
        
    @foo.deleter
    def foo(self):
        print('deleter')

# version 3
class A:

    def foo(self):
        return 'getter'
    foo = getter(foo)
        
    def foo(self, value):
        print('setter', value)
    foo = setter(foo)
        
    def foo(self):
        print('deleter')
    foo = deleter(foo)

# version 4
class A:

    def _foo_getter(self):
        return 'getter'
        
    def _foo_setter(self, value):
        print('setter', value)
        
    def _foo_deleter(self):
        print('deleter')
        
    foo = property(_foo_getter, _foo_setter_, _foo_deleter)

I think that version 1 is the most concise and consistent while being the least prone to typos that could occur in version 2-4. The possibility of this sort of typo was one of the justifcations for the += type of operator and is also why we use super(). The format of version 4 introduces three "hidden" methods and is an unnecessary abstraction.

Again, since we do not currently have @getter, @setter, and @deleter decorators, how does implementing my suggestion break existing code?

[rjdegraff42]

My initial question, which we seem to have gotten away from, was why the original format was chosen when a more consistent, concise, and clear form is available. So far, nobody has been able to explain why the less clear forms are desirable. I'm not telling anyone that my way is better. I'd just like to know why it isn't. Instead I'm getting vague answers and suggestions to implement it myself. Or to just learn to do it the existing way. If everyone thought like that we would all still be coding in Python 2.x. If everyone thought "because that's the way we've always done it" we wouldn't have Python at all.

[rjdegraff42]

Tabled until I learn more about what happens under the hood.