My personal feeling: I would love this idea (DRY gets me almost every time) if it weren't for that awful, terrible `class` keyword hanging out there.

I wouldn't call using class this way "abuse", exactly, but it could be a potential use for an old idea raised more than once in the past: some kind of submodule or namespace definition statement:

class Test:
    ns foo:  # ns a new syntax meaning a namespace, or "submodule", object
        """Docstring for foo"""
        def fget(self):
            print("Getting foo")
            return self._foo
        def fset(self, x):
            print("Setting foo to", x)
            self._foo = x


"I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

On Thu, Jul 2, 2020 at 1:46 PM Matthew Einhorn <> wrote:

On Thu, Jul 2, 2020, 6:30 AM Greg Ewing <> wrote:
On 2/07/20 8:04 pm, Serhiy Storchaka wrote:
> It has a problem with pickling (it is solvable).

Can you elaborate? The end result is a property object just the
same as you would get from using @property or calling property
directly. I don't see how it can have any pickling problems
beyond what properties already have.

> The larger problem is with using private (double underscored) variables
> and super().

I don't know what you're talking about here. I didn't use any
double-underscore names in my example.

I think what he may have meant is that if you tried accessing a double-underscore property of the outer class from the get/set methods, it won't properly de-mangle.

Similarly, if you wanted to overwrite a property by using this property approach in the sub-class, but also call super for the parent's class property getter from within the get/set this wouldn't work!?
Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: