The Power of Python Descriptors | Hacker News Reader

The Power of Python Descriptors

piccolo-orm.com

94 pointspypower9 comments

Writing a class that represents a property on an object so that you can reuse the property as many time as needed is nice.

What is less nice is that the implementation of that idea in python is so tricky. Descriptors come in two flavours and behave differently depending on their type : data descriptor and non data descriptor. Doing something simple as having a descriptor writing a value in an object without clashing with other descriptors/objects is tricky. Thank god they added __set_name__ in 3.6.

For reference, the release notes for this are at https://docs.python.org/3/whatsnew/3.6.html#pep-487-descript... and the PEP is https://www.python.org/dev/peps/pep-0487/

I would be terrified to see how some of the people I've worked with would abuse descriptors... thankfully they never knew about them(or it wasn't a python shop).

I've never understood the rationale that some developers employ for using `@property` (for purely stylistic) reasons and nobody has ever managed to give a very clear explanation of their criteria. Of course the concept is handy here and there, but some people make classes where every method is a property.

i wonder if the people who use `@property` for every method come from a language like ruby where providing getters/setters for every instance variable is a standard thing to do.

@property is useful when updating legacy code, but I agree, there’s not much calling for it. @cachedproperty has a lot more utility.

I used @property a lot when I started with Python. I thought it was idiomatic and 'Pythonic', and I liked the idea of read-only properties, and I name private attrs with a leading underscore, but sometimes I wanted to expose the attr read-only without the underscore.

I rarely use @property now. It doesn't help clarity and isn't used in codebases I'm familiar with. Maybe overuse is a symptom of under-exposure and inexperience. Or maybe it's just personal tastes.

It is just a way to migrate from "simple data access" to "complex data access involving some logic" without changing the API. This is indeed not very useful when you are the only person using your code, because you don't need to provide backwards compatibly guarantees on a source code level, but for library authors this is very much a necessity that saves library users a lot of unnecessary work updating their code, while allowing the library authors the freedom to change the implementation without changing the API.

After getting a bit more used to the way python handles things I've come to realise that properties are basically only necessary if you need to do something special with the setter (even if just to absolutely forbid setting a value).

Woah, I have never seen this in action before. You better believe I am going to find a way to abuse it for metaprogramming. I already have a tendency to over-use @property everywhere.

Reply on news.ycombinator.com