too dynamic - how to avoid?
anton at vredegoor.doge.nl
Thu Oct 2 13:39:03 CEST 2003
"mic" <aldo123 at onet.pl> wrote:
>I've spent last hour trying to debug my code, when I found out that instead
>of executing object's method I accidentaly overridden it with variable (see
>below example). My stupid! But as the system becomes more complex, I begun
>to wonder how to avoid such situations in the future. Does anybody have some
>experiences about that?
> def a(self, value):
> print value
>t = test()
>t.a('my test') <= returns obviously 'my test'
>t.a = 'my test' <= creates object's attribute a, so I'm loosing my method
>From this I can't discern whether you're asking a simple question or
want some sophisticated, nifty programming advice. I'm assuming you
just want some help using the interpreter and the overall programming
If something -whatever- is not quite as expected it's very important
to read the traceback (if there is one) from the interpreter output,
for example in this case trying to call t.a('my test') after t.a has
been bound to a string will result in some complaint from the
interpreter that type 'str' has no call method. It's also very a good
idea to include the traceback in usenet posts since that makes it
possible to receive more specific comments.
Another thing is that it's very handy to use the interactive
interpreter to test pieces of code that behave in unexpected ways.
Just try it out and check the output of your functions. It's not like
indexing an array out of bounds will make your complete system crash
or make it instable, Python is reasonably well defended against simple
The dir command is handy too, for example dir(t.a) will give some info
about what the interpreter thinks t.a is. Next, sprinkling your code
with print statements -turning it into a poor mans debugger system-
works very well for most of the mistakes of this calibre.
Please note that given the dynamic nature of Python the above code
snippet might be exactly what you want and there's no way for the
interpreter yet to do what you intend rather than what you code ;-)
Then there's the debugger inside Idle, but the strategies above are
sufficient in most cases, so that -at least in my case- it's almost
never necessary to use it. I mostly use Scite as an editor and have
pychecker* a single keypress away, but I only use it to doublecheck my
code after it runs as expected.
More information about the Python-list