On Fri, 21 Oct 2005 20:55:47 -0500, Brandon K <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
