Recently I've been working with a strange python module (which I won't name here). The module apparently works well. Though, when I read through the sources I felt bad. The code was so unpythonic that a direct translation from Java would have given more pythonic results.
Object oriented to the bone, especially when not necessary. Type-checks with type(foo) == ....
As if the PEP8 was burned at the stake...
I have to fight with the temptation to just fix the whole code, which would probably break everything. The tests are there but usual ways to run them do not work.
How is that I'm not surprised that I found a .pydevproject file in the root? Ah, once there were just vim and Emacs. And the CLI. And things were harder to make it work, but then they worked. For everyone.
2 comments:
I think the quality of code not to be linked with the IDE, but something I especially like about the Java world is Maven.
Once your pom.xml is setup, you can open and work with such project on almosty any Maven-supporting IDE, and every IDE knows how to compile code, how to run tests, et cetera.
In the python world there's no "one tool to rule them all". Distutils(2)/Setuptools/Distribute/Virtualenv/Buildout are overlapping in functionality, allow arbitrary code inside their scripts, leading to All Kind Of Awful Things inside what should be basic build scripts (not true for distutils2), not so powerful (dependency management and they're not so easy to use (documentation is poor) nor they're very well supported by different IDEs.
This makes it a bit harder to convey the notion of "one way to do it" in Python build scripts.
Of course quality of code is not linked to the IDE.
Somewhat I would not even say that the quality of code is *low*. I think the developer is a skilled engineer, he is just not familiar with Python idioms.
In this context it unsurprising that the IDE of choice is Eclipse. Although PyDev offer extremely interesting features, many old time python users are still with more traditional tools (even though some made the transition).
About maven... nothing against that. And I understand that we lack such a tool in Python.
However, we have nosetest and other tools for testing, which is the problem I had with the project mentioned (which had no external dependencies, no C extensions, etc).
Somewhat I think that the project was only tested inside Eclipse and the author never tried if nosetest and similar tools worked. Since some of the tests fail, I do not even know if it is a problem of some black magic in setting up the tests or if the tests are really broken.
Post a Comment