Hi, [Gerrit Holl]

...

def mtime(): doc = "Modification time"

def get(self): return os.path.getmtime(str(self))

def set(self, t): return os.utime(str(self), (self.atime, t))

return get, set, None, doc mtime = property(*mtime())

I like it, because it's very readable for me, and doesn't clutter the namespace. Two questions about this style:

- Is it tolerable to use it in the standard library (PrePEP)? - Should it be advised for or against in PEP 8, or neither?

[Guido van Rossum]

I don't like it, and I'd rather not see this become a standard idiom.

OK.

Personally, I don't see the issue with the namespace cluttering (what's bad about it?) and I actually like that the getter/setter functions are also explicitly usable (hey, you might want to use one of these as the key argument to sort :-).

My objection against the def is that it requires a lot of sophistication to realize that this is a throw-away function, called just once to return argument values for the property call. It might also confuse static analyzers that aren't familiar with this pattern.

I was thinking of it as analogue to classmethod() and staticmethod(), but it isn't, of course. The getter/setter are still accesible through the property object itself, but I get your point. I think there is a problem with the current way of defining properties. A property commonly exists of several parts. These parts form one object. But the parts are not grouped by indentation. In my opinion, readability would be enhanced if they would. One way to do this is adding syntax - discussed about a year ago with no conclusion. Another way is to use a class with a metaclass - not clean, because you aren't creating a class after all. I thought this would be a good concession, but it has similar disadvantages. Do you agree that there is a a problem here? Should Guido van Rossum's opinion be included in PEP 8? yours, Gerrit.