10

As a learning exercise, I'm trying to implement a class which will emulate the behavior of python's complex builtin, but with different behavior of the __str__ and __repr__ methods: I want them to print in the format...

(1.0,2.0)

...instead of:

(1+2j)

I first tried simply subclassing from complex and redefining __str__ and __repr__, but this has the problem that when non-overridden methods are called, a standard complex is returned, and printed in the standard format:

>>> a = ComplexWrapper(1.0,1.0)
>>> a
(1.0,1.0)
>>> b = ComplexWrapper(2.0,3.0)
>>> b
(2.0,3.0)
>>> a + b
(3+4j)

When the desired output is (3.0,4.0).

I was reading about metaclasses and thought they would solve my problem. Starting from the answer in Python Class Decorator, my current implementation is as follows:

def complex_str(z):
    return '(' + str(z.real) + ',' + str(z.imag) + ')'
def complex_repr(z):
    return '(' + repr(z.real) + ',' + repr(z.imag) + ')'

class CmplxMeta(type):
    def __new__(cls, name, bases, attrs):
        attrs['__str__'] = complex_str
        attrs['__repr__'] = complex_repr
        return super(CmplxMeta, cls).__new__(cls, name, bases, attrs)

class ComplexWrapper(complex):
    __metaclass__ = CmplxMeta

Unfortunately, this seems to have the same behavior as the previous solution (e.g. when two ComplexWrapper instances are added to each other).

I admit, I don't fully understand metaclasses. Maybe my problem can be solved in a different way?

Of course, I could manually redefine the relevant methods such as __add__, __subtract__, etc. But that would be very repetitive, so I would prefer a more elegant solution.

Any help appreciated.


EDIT: Response to agf's answer:

So a number of things I don't understand about your code:

  1. Where does the __new__ method of the ReturnTypeWrapper metaclass get its arguments from? If they are passed automatically, I would expect in this case that name = "Complex", bases = (complex), dict = {}. Is that correct? Is this method of automatic passing of class data specific to metaclasses?

  2. Why do you use cls = type.__new__(mcs, name, bases, dct) instead of cls = type(mcs, name, bases, dct)? Is it just to avoid confusion with the "other meaning" of type()?

  3. I copied your code, and added my special implementations of __str__ and __repr__ in your ComplexWrapper class. But it doesn't work; printing any object of type Complex just prints in the standard Python format. I don't understand that, as the two methods should have been picked up in the for loop of the metaclass, but should have been overridden by my definitions afterward.

The relevant section of my code:

class Complex(complex):
    __metaclass__ = ReturnTypeWrapper
    wrapped_base = complex
    def __str__(self):
        return '(' + str(self.real) + ',' + str(self.imag) + ')'
    def __repr__(self):
        return '(' + repr(self.real) + ',' + repr(self.imag) + ')'

And its behavior:

>>> type(a)
<class 'Cmplx2.Complex'>
>>> a.__str__
<bound method Complex.wrapper of (1+1j)>
>>> a.__str__()
'(1+1j)'
>>> 

Thanks again for your answer and feel free to edit/remove the above if you address them in your answer!

Community
  • 1
  • 1
mszep
  • 410
  • 3
  • 12
  • 1
    I numbered your questions. 1. You're almost right; `dct` will be something like `{'__module__': '__main__', '__metaclass__': , 'wrapped_base': }`, it's the `dict` that will become the class' `__dict__` attribute, once it is created. – agf May 27 '12 at 18:04
  • 1
    2. Try it. You have to call `__new__` directly to use a custom metaclass, or else Python does it's special magic to put `type` in as the first argument -- here you want `ReturnTypeWrapper` as the first argument. – agf May 27 '12 at 18:05
  • 1
    3. That was my fault. First of all, I was wrapping even methods that had been overridden. That's fixed. Second, `complex.real` and `complex.imag` are properties / descriptors, so they were being wrapped. I special-cased it so they won't be, but now, like `__coerce__`, `.imag` returns a `complex`, not your subclass. That could also be worked around if needed. – agf May 27 '12 at 18:34
  • 1
    I also added `__str__` and `__repr__` methods to show you how to get the output you want, with `__repr__` modified to be `eval`-able to get back the object (as `repr` output should be). – agf May 27 '12 at 18:35
  • Thanks again, this is a great help. 1. and 2. are clear to me now. For 3., your fix I think works better than you think, since .imag actually returns a float, so there's no problem there. I may try implementing __coerce__ later. – mszep May 27 '12 at 19:19

1 Answers1

9

Your current approach won't work. How you define your class isn't the issue -- the methods of complex are creating new instances of complex when you call them, rather than using the type of the input objects. You'll always get back instances of complex rather than ComplexWrapper, so your customized methods won't be called:

>>> type(ComplexWrapper(1.0,1.0) + ComplexWrapper(2.0,3.0))
<type 'complex'>

Instead, you need to convert the new complex objects returned by the methods of complex to return objects of the derived class.

This metaclass wraps all the methods of the specified base class and attaches the wrapped methods to the class. The wrapper checks if the value to be returned is an instance of the base class (but excluding instances of subclasses), and if it is, converts it to an instance of the derived class.

class ReturnTypeWrapper(type):
    def __new__(mcs, name, bases, dct):
        cls = type.__new__(mcs, name, bases, dct)
        for attr, obj in cls.wrapped_base.__dict__.items():
            # skip 'member descriptor's and overridden methods
            if type(obj) == type(complex.real) or attr in dct:
                continue
            if getattr(obj, '__objclass__', None) is cls.wrapped_base:
                setattr(cls, attr, cls.return_wrapper(obj))
        return cls

    def return_wrapper(cls, obj):
        def convert(value):
            return cls(value) if type(value) is cls.wrapped_base else value
        def wrapper(*args, **kwargs):
            return convert(obj(*args, **kwargs))
        wrapper.__name__ = obj.__name__
        return wrapper

class Complex(complex):
    __metaclass__ = ReturnTypeWrapper
    wrapped_base = complex
    def __str__(self):
        return '({0}, {1})'.format(self.real, self.imag)
    def __repr__(self):
        return '{0}({1!r}, {2!r})'.format(self.__class__.__name__, 
                                          self.real, self.imag)


a = Complex(1+1j)
b = Complex(2+2j)

print type(a + b)

Note that this won't wrap the __coerce__ special method, since it returns a tuple of complexs; the wrapper can easily be converted to look inside sequences if necessary.

The __objclass__ attribute of unbound methods seems to be undocumented, but it points to the class the method is defined on, so I used it to filter out methods defined on classes other than the one we're converting from. I also use it here to filter out attributes that aren't unbound methods.

agf
  • 171,228
  • 44
  • 289
  • 238
  • Thank you very much for your answer. However, I'm not sure I understand what's going on. Since the comments are apparently limited in length, I'll edit the question to clarify. – mszep May 27 '12 at 13:35
  • So two more comments and one question: 1. you have an indentation error in the definition of __repr__ which StackOverflow won't let me correct since it's only whitespace. 2. Other than that, it works as it should, but I don't understand why you take the abs() of the imaginary parts in __str__ and __repr__. 3. I'm wondering about the line wrapper.__name__ = obj.__name__ line you added... is it just there for cosmetic reasons? – mszep May 27 '12 at 19:24
  • 1
    @mszep 1. Fixed. 2. My mistake, I thought it returned a `complex`. 3. Semantic as well as cosmetic -- if you `print Complex.__add__, Complex.__sub__` the result should be meaningful; without that line they're both `Complex.wrapper`. – agf May 27 '12 at 21:28