newb question about @property

Bill BILL_NOSPAM at whoknows.net
Sun Oct 1 02:46:53 EDT 2017


Steve D'Aprano wrote:
> Circle
> didn't use any setters, but I could have let you set the diameter, which in
> turn would set the radius:
>
> circle.radius = 2
> assert circle.diameter == 4
> circle.diameter == 2  # requires a setter
> assert circle.radius == 1
>
> Getting that to work is left as an exercise :-)

I may start that exercise in a few minutes!

>
> But most commonly, computed attributes need to store some data aside, somewhere.
> You could use a global variable, or write it to a file, or stick it in a list.
> All of these things have obvious problems, so the most sensible approach it to
> stick the data in a private attribute.
>
> The interpreter doesn't enforce notions of private/public when it comes to
> Python classes, but there's a very strong convention that anything starting
> with a single underscore is private.
>
>
>
> [1] Technically, the interpreter knows nothing about properties. What it cares
> about is *descriptors*. Properties are just one kind of descriptor, as are
> methods. But I'm intentionally not talking about the gory details of
> descriptors. Feel free to ask if you care, but honestly, you don't need to care
> unless you are writing your own descriptor class.
>
>
Thank you, and everyone else who has contributed to this thread, for 
helping me.  Each contribution I read helped me to get further ahead!

I watched an example on YouTube where someone wrote a simple descriptor 
("@Time_it) to output the amount of time that it took ordinary functions 
to complete.    To be honest, I AM interested in descriptors. I may 
reexamine whether David Beazley has more to say about them in his book  
"Python: Essential Reference", which I have been reading. Obviously, I 
still have some gaps in my understanding after my first reading.

If you were going to show non-Python users, say science undergraduates 
and faculty, that Python is an interesting tool (in 45 minutes), would 
one delve into descriptors? I am thinking maybe. Here is what I am 
thinking at this moment: trivial applications (probably), list 
comprehensions (definitely), generators (maybe briefly).   Whatever I 
would discuss, I think ending with descriptors could be a strong finish. 
But I'm certainly not merely interested for the sake of my talk, I 
obtain some satisfaction in learning how things work.  If you can 
suggest any references for descriptors which you think are good, I would 
be interested.

Thanks,
Bill




More information about the Python-list mailing list