[HN Gopher] The Power of Python Descriptors
       ___________________________________________________________________
        
       The Power of Python Descriptors
        
       Author : pypower
       Score  : 73 points
       Date   : 2022-01-24 14:31 UTC (8 hours ago)
        
 (HTM) web link (piccolo-orm.com)
 (TXT) w3m dump (piccolo-orm.com)
        
       | TBurette wrote:
       | 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.
        
         | milliams wrote:
         | 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/
        
       | jcoq wrote:
       | 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.
        
         | zem wrote:
         | 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.
        
         | pure_simplicity wrote:
         | 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.
        
         | nealabq wrote:
         | 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.
        
         | [deleted]
        
         | aidos wrote:
         | @property is useful when updating legacy code, but I agree,
         | there's not much calling for it. @cachedproperty has a lot more
         | utility.
        
       | whalesalad wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2022-01-24 23:15 UTC)