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