Happy new year Keith! 

Yes, I have considered that, but the builtin decorator with support for a 
setter is only supported from Python v2.6. That's why I've used a custom one 
(based on a decorator made by someone else. 

Also, we have the PropWithDraw decorator which is very convenient, although it 
might
be possible to implement something like that with the builtin property.

I don't like to replace the decorator with the builtin one until 2.6 is more 
mainstraim. And that might be a while; there are still a lot of people 
depending on Python 2.4. 

The only solution I can imagine is to replace it with a custom decorator that 
does not use sys.settrace. 

I think, though I haven't tried, that you can use properties with setters in 
2.4, but you have to use the x = property(...) syntax.  This would mean quite a 
bit of rewriting, but I see no fundamental problem with this.  Alternatively, 
it's got to be possible to write a property decorator for 2.4 that would 
provide the capabilities of 2.6, since those are just syntactic sugar.  But 
again, every property would need to be rewritten.

This comment [http://code.activestate.com/recipes/410698/#c6] provides a way to 
do properties much like the current method in visvis, but without messing 
around with sys.settrace().  It would require a bit of boilerplate to be added 
to each property (explicitly labeling the docstring and adding the return 
locals() statement), but this might be accomplished with a clever sed script.

Mmm, I'm getting more convinced that we should remove the settrace stuff. It 
just isn't right to use it.

I looked at the link you send. I like the metaclass thing, but find the use of 
it (making a class definition to define a property) a bit too strange ...

I like the simple property where you have to return locals() at the end. It 
would be nice if that was not necessary, but I don't think it's possible 
(except with using settrace). It is very easy to make it use the docstring 
though! This means we only have to add "return locals()" at every property. 
That's not too bad. If you're ok with this change, I can do it tonight.

def newProp( fcn ):
    D = fcn()
    if not 'doc' in D:
        D['doc'] = fcn.__doc__
    return property( **D )


class Example(object):

    @newProp
    def myattr():
        """This is the doc string."""

        def fget(self):
            return self._value

        def fset(self, value):
            self._value = value

        def fdel(self):
            del self._value

        return locals()

I knew there had to be a way to get the docstring easily, but I was wasting my 
time trying to convince locals() to return it instead of just reading it from 
the function itself.

The settrace method always made me a bit nervous, since I didn't know what it 
did.  I like this method better, although the need to return locals() is a bit 
annoying.  In the definition of newProp, we may want to check that D has no 
keys besides fget, fset, fdel, and doc.  I don't have a clear use case when 
this would happen, but it's not impossible that we'd want a helper function is 
a property somewhere.

I know a use case: someone accidentally typed the function name wrong, for 
instance "getf" instead of "fget". Would be nice to help the user point out 
what is wrong, instead of getting some weird error about keyword args :)

In theory, you could do a lot with this simple approach. You could define other 
functions or data besides fget, fset and fdel. I have no idea why, but it can 
be pretty powerful. But anyway, lets just limit to fget,fset,fdel and doc for 
now...

This issue was closed by revision c96c5f8b1db9.

Thank You, Thank You, Thank You!

I just pulled this and tested it in Eclipse with the pydev debugger.  It works 
great!

-Keith