Kent Johnson said unto the world upon 2005-04-10 15:11:
As John Ridley suggests, you have to balance creation and deletion of
Wall_clock instances. But unfortunately del wc does not necessarily call
Wall_clock.__del__() immediately.
Hi Kent and all,
OK, the delay between the statement del(wc) and the call of
Wall_clock.__del__() helps explain a good deal. Thanks for pointing
that out!
See below for more...
Brian van den Broek wrote:
def check_point(self, check_point_name = None):
'''Creates a new _Check_point instance; appends it to .data.
<SNIP>
>>> new_wclock = Wall_clock() # This passes
You need a matching del new_wclock() here.
'''
def interval(self, interval_name = None):
'''
<SNIP>
>>> same_name = wclock.interval('F')
Traceback (most recent call last):
...
Interval_name_conflictError
You need a matching del wclock here. BUT it still doesn't work because
__del__() doesn't get called.
If you read the Note under the description of __del__() on this page
http://docs.python.org/ref/customization.html
it says that in the case of an exception, references are retained in the
stack track object. I tried the workarounds suggested with no luck. but
taking out the line that causes the exception (and adding the missing
del) does in fact make the test work.
OK, that's helpful; thanks. Making the changes you suggest does indeed
fix the failure problem. :-)
But: it still leaves me wondering why removing either a) the one-line
no-doctest-containing docstring of the Wall_clock class or b) the
unreferenced Wall_clock.stop_interval method made my original test
code pass without needing to effect the changes you suggest. That
seems really odd to me.
As far as doctests being independent, each doctest has it's own copy
globals(). But your class has its own internal state, this is not
affected by globals(). Basically there are side-effects to the use of
your class; doctest can't account for them.
I've not fully grokked the doctest code (which I delved into after Lee
Harr suggested I do so), but I would have thought that each doctest
had its own copy of the Wall_clock class from copying globals. But
here, I surely have more work to do myself :-)
Personally I don't see any compelling reason why Wall_clock() should be
a singleton. It could easily be a module with global functions and
global state, or you could allow clients to have multiple instances to
time different things.
I'm not sure I see a reason anymore, either. :-)
The code that I removed before posting allows for multiple things to
be timed, but all timings are relative to the first instantiation of
the Wall_clock class. _Check_points, on creation, store how many
seconds have elapsed since the Wall_clock instance was created,
_Intervals how long between their start and stop signals, as well as
how long from Wall_clock instance creation their start signal was
sent. The thought was that the results would be easier to interpret
were all timings relative to a single initiation point, rather than
having timings of instance 1 relative to instance 1's initiation, and
instance 2's relative to its.
From a usability standpoint, I think I have settled on a Borg, where
the first instances start time is the one to which all timings will be
relative.
But, in a way, which route is best is something of a side issue
(though I do appreciate the input). I took this up to primarily to
explore various possible structures just for learning about them.
So, apart from the open questions (about why the unreferenced method
and the no-doctest class docstring made a difference), I think I can
count my original problem solved. I know how to make my tests work as
excepted, and that is the main thing.
Sincere thanks to everyone who worked their way through my mammoth
original post; I very much appreciate the contributions!
Best to all,
Brian vdB
_______________________________________________
Tutor maillist - [email protected]
http://mail.python.org/mailman/listinfo/tutor
