Ed Leafe wrote: > On Aug 13, 2007, at 1:11 PM, Paul McNett wrote: > >> I just don't see how this particular case (overriding __init__ at the >> user subclass level) will require different user code for different UI >> toolkits... > > I'm thinking that things that are implemented one way in wxPython, > such as dTextBox/dEditBox, will be completely different with another > toolkit. There are so many things that go on between the __init__s of > the classes and mixins that have to happen in a certain order that I > do not feel comfortable guaranteeing that a certain value will always > be defined at a particular point in the process. Telling someone that > they are free to override __init__() if they like implies that sort > of promise.
I think that in the context of a user subclass, that it doesn't need to be a problem (all the important stuff happens upstream at the Dabo level). However, I don't want to encourage people to use __init__ instead of beforeInit, afterInit, initProperties, and afterInitAll, because I don't want to have to support people that do that. > Also, can you imagine this code: > > class MySubText(dabo.ui.dTextBox): > def __init__(self, *args, **kwargs): > super(MySubText, self).__init__(*args, **kwargs) > print "This is in the __init__() method" > > def afterInit(self): > print "This is the afterInit() method." > > How do you explain that the afterInit() code will be firing *before* > the __init__() code does? Do we really want that sort of headache? Well, that is easily explained: "If you can't explain why this is happening for yourself, you should follow our recommendations to never override __init__." ;) > Our design is extremely smart and effective. All Dabo users should > be strongly encouraged to work with the framework, not against it. > Just because someone like Uwe insists on paddling upstream > unnecessarily doesn't mean we should ever encourage anyone else to do > the same. Agreed about our smart and effective design. I was simply saying that it may not hurt to put a sidenote in the docs to explain to Pythonistas why it is done this way, and that it would theoretically work to override __init__, as long as the developer knows what they are doing. -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
