[TIP] {Disarmed} Re: Testing multi-threaded applications

[Bernhard Mulder]

>> My current code is something like this:
>> from SystemInterfaces import mytime
>> sleep = mytime.sleep

>yes but you do not know what is the real implementation behind neither.

What I have found is that each larger application needs a set of
conventions which defines how things are done. Often developers do a
poor job of making these conventions explicit, and you have to reverse
engineer the conventions.

As for the code fragment above, the convention is that the submodules
my<something> shadow the standard modules <something>, except
(possibly) for testing. Once you are aware of this convention, the
code is clear and simple.

One of the problems of discussing questions of style is that people
are exposed to different conventions, and have thus different notions
of what is 'simple' and 'obvious'. Sometimes I dabble in an
application which has a lot of 'setters' and 'getters', hiding
instance attribute access behind functions. I have heard the argument
that such getters and setters are pointless in Python, since you can
always introduce descriptors to do whatever you want behind the scenes
of an attribute access. setters have the slight advantage that you
might notice a misspelling slightly earlier, but if you do not catch a
misspelling in your unit testing (quickly), you are asking for trouble
anyway, or so goes the argument.

So are getters and setters bad for Python programming? If you don't
know descriptors, there is no contest: getters and setters are a way
to maintain flexibility. If you are unclear what descriptors do,
getters and setters are still the superior choice, since you do not
want to use constructs which you don't understand clearly. If you *do*
understand descriptors, getters and setters might be considered to be
just noise, not really contributing anything.

One rule of thumb I use in my programming is that the less code I have
to write, the better. Often I have to struggle for quite a while to
come up with code which is both concise and correct. Using this
measure, just having to adjust the import clauses seems to beat
passing standard functions through defaulted arguments, possibly
through multiple levels, and for several parameters, obscuring, as I
wrote earlier, the "testing artifacts" from the requirements of the
algorithmic code.

Of course, I do not want to write obscure code, but then, what
constitutes obscure code might be function of background and
convention. Having said that, I *do* believe that there is something
objective like "conceptual complexity", I just don't know how to
define it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.idyll.org/pipermail/testing-in-python/attachments/20070514/a2969485/attachment.htm