[Python-Dev] PEP 8 addition: Preferred property style?

Gerrit Holl gerrit at nl.linux.org
Thu Jan 22 16:21:38 EST 2004


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


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


More information about the Python-Dev mailing list