[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?


More information about the Edu-sig mailing list