[IronPython] __init__ ignored in favor of base class constructor? - blocker

[Michael Foord]

Dan Eloff wrote:
> On Sun, Nov 30, 2008 at 8:30 AM, Michael Foord
> <fuzzyman at voidspace.org.uk> wrote:
>   
>> Hello Dan,
>>
>> I can't find this assembly to experiment - but when you subclass a .NET type
>> in IronPython you override the constructor by overriding '__new__' and not
>> '__init__'. Perhaps this is the cause of your problem? (If the default
>> constructor takes two arguments then merely supplying an __init__ method
>> that only takes one won't stop the default two argument constructor being
>> called.)
>>
>>     
>
> I don't think I've ever subclassed a .NET type that has a default
> constructor taking an argument, hopefully the problem here is with me
> and not IronPython :) I thought __new__ might be the one to use, but I
> got these errors with __new__:
>
> class MyTheme(Theme):
>     def __new__(cls):
>         return Theme.__new__(cls,
> Application.GetResourceStream(Uri('theme.xaml', UriKind.Relative)))
>
> TypeError: default __new__ does not take parameters.
>
>   

Looks like the subclassing bug *again*. :-)

(i.e. it looks like  Theme.__new__(...) is actually being diverted back 
to MyTheme.__new__(...))

Michael

> If I use:
>
> class MyTheme(Theme):
>     def __new__(cls):
>         return Theme.__new__(cls)
>
> TypeError: MyTheme() takes at least 2 arguments (1 given)
>
> Back to square one. Do you have some idea what I'm doing wrong here?
> The assembly is from the Silverlight Toolkit:
> http://www.codeplex.com/Silverlight
>
> -Dan
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog