coloring a complex number

[Arthur]

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')
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
'complex' when I am hoping to have been subclassing the built_in numeric
type - complex.

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
BLUE

which is very good.

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.

Art

 

[Brandon K]

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')

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
'complex' when I am hoping to have been subclassing the built_in numeric
type - complex.

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

BLUE

which is very good.

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.

Art

----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

 

[Kent Johnson]

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')

In general when you subclass an immutable type you have to override __new__ rather than __init__. There is some explanation and example here:
http://www.python.org/2.2.3/descrintro.html#__new__

Kent

 

[Bengt Richter]

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

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.:
... def __new__(cls, *args, **kws):
... return complex.__new__(cls, *args)
... def __init__(self, *args, **kws):
... self.color=kws.get('color', 'BLUE')
... 'BLUE'

Or as in what you found, below:
'RED'

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

HTH

Regards,
Bengt Richter