Here is the problem: these methods should create instances of Row,
Column and Navbar. But this leads to circular imports.
It should not; Python is not Java.

Use modules to group your class definitions conceptually. There is no
need whatever to separate every class into a different module.
If there is a consensus, and it is really desireable to put all these related classes into the same module, then this is what I'm going to do.

This might be a bad idea, but then please tell me why it is bad, and
what would be the right code pattern for this task.
Not only does it lead to the problem you've described, it makes the code
needlessly difficult to read.

Pyth is not Java
<URL:http://dirtsimple.org/2004/12/python-is-not-java.html>.
This is funny, because I was working for wxPython for years and this article is making an example with wxPython. It is one of the best toolkits around. Some years ago I wondered why did they not follow PEP8 and used lower case method names. Then I found out that these are C++ wrapper classes, many of them automatically generated from C++ code. So that is why. But by that time I was using captialized method names for UI widgets everywhere, and I guess this is my bad habit now. Probably when it comes to UI widgets I do not think the Pythonic way for the same reason.

I never know when to put classes in different modules. I usually draw an UML diagram and group classes into packages. Wich makes sense because there can be sub-groups with subpackages. But I'm always confused with modules, I don't know why.

Thanks for the help.

--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to