coloring a complex number

[Bengt Richter]

On Fri, 21 Oct 2005 20:55:47 -0500, Brandon K <prince_amir86 at yahoo.com> wrote:

>I'm not 100% sure about this, but from what it seems like, the reason 
>method B worked, and not method a is because class foo(complex) is 
>subclassing a metaclass.  So if you do this, you can't init a meta class 
>(try type(complex), it equals 'type' not 'complex'.  type(complex()) 
>yields 'complex'), so you use the new operator to generator a class on 
>the fly which is why it works in method B.  I hope that's right.
>
>-Brandon
>> Spending the morning avoiding responsibilities, and seeing what it would
>> take to color some complex numbers.
>> 
>> class color_complex(complex):
>>         def  __init__(self,*args,**kws):
>>                 complex.__init__(*args)
>>                 self.color=kws.get('color', 'BLUE')
>> 
>>>>> a=color_complex(1,7)
>>>>> print a
>> (1+7j)                                                      #good so far
>>>>> a=color_complex(1,7,color='BLUE') 
>> Traceback (most recent call last):
>>  File "<pyshell#37>", line 1, in -toplevel-
>>    a=color_complex(1,7,color='BLUE')
>> TypeError: 'color' is an invalid keyword argument for this function
>> 
>> No good... it seems that I am actually subclassing the built_in function
No, complex is callable, but it's a type:
 >>> complex
 <type 'complex'>

>> 'complex' when I am hoping to have been subclassing the built_in numeric
>> type - complex.
>> 
You need to override __new__ for immutable types, since the args that build
the base object are already used by the time __init__ is called, and UIAM the
default __init__ inherited from object is a noop. However, if you define __init__
you can choose to process the other args in either place, e.g.:

 >>> class color_complex(complex):
 ...     def __new__(cls, *args, **kws):
 ...         return complex.__new__(cls, *args)
 ...     def __init__(self, *args, **kws):
 ...         self.color=kws.get('color', 'BLUE')
 ...
 >>> a=color_complex(1,7)
 >>> a
 (1+7j)
 >>> a=color_complex(1,7, color='BLUE')
 >>> a
 (1+7j)
 >>> a.color
 'BLUE'

Or as in what you found, below:

>> but some googling sends me to lib/test/test_descr.py
>> 
>> where there a working subclass of complex more in
>> accordance with my intentions.
>> 
>> class color_complex(complex):
>>    def __new__(cls,*args,**kws):
>>            result = complex.__new__(cls, *args)
>>            result.color = kws.get('color', 'BLUE')
>>            return result
>> 
>>>>> a=color_complex(1,7,color='BLUE')
>>>>> print a
>> (1+7j)
>>>>> print a.color
>> BLUE
>> 
>> which is very good.

 >>> a=color_complex(1,7, color='RED')
 >>> a
 (1+7j)
 >>> a.color
 'RED'

(just to convince yourself that the default is just a default ;-)


>> 
>> But on the chance that I end up pursuing this road, it would be good if
>> I understood what I just did. It would certainly help with my
>> documentation  ;)
>> 
>> Assistance appreciated.
>> 
>> NOTE:
>> 
>> The importance of the asset of the depth and breadth of Python archives
>> -  for learning (and teaching) and real world production - should not be
>> underestimated, IMO. I could be confident if there was an answer to
>> getting the functionality I was looking for as above, it would be found
>> easily enough by a google search.  It is only with the major
>> technologies that one can hope to pose a question of almost any kind to
>> google and get the kind of relevant hits one gets when doing a Python
>> related search.  Python is certainly a major technology, in that
>> respect.  As these archives serve as an extension to the documentation,
>> the body of Python documentation is beyond any  normal expectation.
>> 
>> True, this asset is generally better for answers than explanations.
>> 
>> I got the answer I needed.  Pursuing here some explanation of that answer.
>> 
HTH

Regards,
Bengt Richter