>> My current code is something like this:<br>>> from SystemInterfaces import mytime<br>>> sleep = mytime.sleep<br><br>>yes but you do not know what is the real implementation behind neither.<br><br>What I have found is that each larger application needs a set of<br>conventions which defines how things are done. Often developers do a<br>poor job of making these conventions explicit, and you have to reverse<br>engineer the conventions.<br><br>As for the code fragment above, the convention is that the submodules<br>my<something> shadow the standard modules <something>, except<br>(possibly) for testing. Once you are aware of this convention, the<br>code is clear and simple.<br><br>One of the problems of discussing questions of style is that people<br>are exposed to different conventions, and have thus different notions<br>of what is 'simple' and 'obvious'. Sometimes I dabble in an<br>application which has a lot of 'setters' and 'getters',
hiding<br>instance attribute access behind functions. I have heard the argument<br>that such getters and setters are pointless in Python, since you can<br>always introduce descriptors to do whatever you want behind the scenes<br>of an attribute access. setters have the slight advantage that you<br>might notice a misspelling slightly earlier, but if you do not catch a<br>misspelling in your unit testing (quickly), you are asking for trouble<br>anyway, or so goes the argument.<br><br>So are getters and setters bad for Python programming? If you don't<br>know descriptors, there is no contest: getters and setters are a way<br>to maintain flexibility. If you are unclear what descriptors do,<br>getters and setters are still the superior choice, since you do not<br>want to use constructs which you don't understand clearly. If you *do*<br>understand descriptors, getters and setters might be considered to be<br>just noise, not really contributing anything.<br><br>One rule of thumb
I use in my programming is that the less code I have<br>to write, the better. Often I have to struggle for quite a while to<br>come up with code which is both concise and correct. Using this<br>measure, just having to adjust the import clauses seems to beat<br>passing standard functions through defaulted arguments, possibly<br>through multiple levels, and for several parameters, obscuring, as I<br>wrote earlier, the "testing artifacts" from the requirements of the<br>algorithmic code.<br><br>Of course, I do not want to write obscure code, but then, what<br>constitutes obscure code might be function of background and<br>convention. Having said that, I *do* believe that there is something<br>objective like "conceptual complexity", I just don't know how to<br>define it.<br><br>