[Edu-sig] Properties use case
Arthur
ajsiegel at optonline.net
Wed Mar 15 00:52:19 CET 2006
I don't know whether this is theoretical, philosophical, or in any way
relevant to what we are *supposed* to be discussing here - but to break
what I consider to be an uncomfortable silence I thought I'd throw it
out into the excess bandwidth, nonetheless:
I do in fact use properties in various places in my code, and but not
generally in ways I find compelling or truly functional - maybe some
nuance of "interface" that I could easily live without. I seem ,
however, to have come across my first more compelling use case.
I went with the creation of a mutable complex number type, which I then
inherit from and use down the line. But when I send instances of
classes derived from this custom type to use as elements of a Numeric
Userarray, there is no way that I have found to be able to tell Numeric
that if it treats these instances as if they were built-in complex
numbers, things should work out OK. Numeric seems to insist on creating
arrays of Python instances, and then insists it does not know how to do
math with Python instances.
So properties come in handy essentially to do casting - from the custom
Complex type to the built-in complex type on the way into the UserArray,
and in reverse on the way out - i.e, set and get. This only
additionally meant customizing the Numeric UserArray to derive from
object (it doesn't come that way) , before I go further with it, so that
properties "take".
I am sure I am taking at least a bit of a performance hit by going this
route. Does anyone see something simple I may be missing here to get to
where I am trying to get, without the hit?
Art
More information about the Edu-sig
mailing list