Metallicow wrote:
More questions:
1. What would be the easiest way for me to generate the html docs for
just my few modules with the sphinx generator, so as to test what they
will look like. I didn't find any documentation on the phoenix page.
You could use the Sphinx tools directly for initial tests. You will also want to have the Phoenix build tool build the docs before you you are finished, as it does some post processing of the generated text files before running it all through Sphinx. So you will want to make sure that those tweaks are done correctly for your documentation. Once you have done the first pass of generating all of the docs then subsequent updates do not take too long to process so it isn't too bad to just run the build.py commands for your intermediate testing too.
2. I read a bit about mixins on someones site... rumor is...
Ex:
class MyClass(wx.Frame, MyMixin):
vs.
class MyClass(MyMixin, wx.Frame):
Does Inheritance Position/Order really matter?
Yes. It determines the MRO (Method Resolution Order) which is what determines which instance of a method it uses when you call it, and which is the next one called if the method uses super().
If so which one is correct?
It depends.
3. When binding events in a mixin, does lambda provide any extra
benefits?
No, not any beyond using a lambda in a non-mixin class hierarchy.
SmartHighlighting Ex: if extra functionality is desired without
overwriting the default handler. Im guessing event.Skip() should always
be wisely placed somewhere in the event(beginning or end).
It doesn't really matter where it is called. It just sets a flag that is checked after the event handler returns.
4. Is it prefered that short sample apps be in a library resource at the
end of the file? Or should they explicitly be seperate?
Yes, all of the above. I think it is nice to have a simple "smoke test"[1] in the module itself that just proves that it works and not much (if any) more. Then there should be a module in the demo that shows a real-world example of the widget in as close to a real-world context as possible, and which also includes overview text and detailed comments that a newbie can use to learn about how to use the widget. Finally, there should be a module added to unittests that fully exercises as much of the code as possible and which includes cross-checking and asserts to verify things like intermediate results, that events were sent/received, that expected failures happened, etc.
[1] This term comes from the hardware world where the test consists of applying power to the device being tested and if there is no smoke, sparks, melting components or other signs of fundamental failure then the test passes.
···
--
Robin Dunn
Software Craftsman
