newb question about @property
Steve D'Aprano wrote:
> 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.
>  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