On 5/10/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 5/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
>
> > >What if they have defined a do_stuff that dispatch on ClassC that is a
> > >subclass of ClassA? Good luck in figuring out what the code does.
>
> > >With the non-overloaded version you also have the ability to insert
> > >debug print statements to figure out what happens.
>
> > @before(do_stuff)
> > def debug_it(ob: ClassC):
> > import pdb
> > pdb.set_trace()
>
> I think this may be backwards from his question. As I read it, you
> know about class A, but have never heard about class C (which happens
> to be a substitute for A). Someone added a different do_stuff
> implementation for class C.
It is backwards, using the debugger solves a problem that should not
have been there in the first case. Let's assume the original flatten
example again:
from overloading import overload
from collections import Iterable
def flatten(ob):
"""Flatten an object to its component iterables"""
yield ob
@overload
def flatten(ob: Iterable):
for o in ob:
for ob in flatten(o):
yield ob
@overload
def flatten(ob: basestring):
yield ob
Let's also assume that:
1. The above code is stored in a file flatten.py.
2. There is a class MyString in file mystring.py which is an Iterable
but which is not a basestring.
3. There is a third file foo.py which contains
RuleSet(flatten).copy_rules((basestring,), (MyString,))
4. There is a fourth file, bar.py, which contains
ms = MyString('hello')
print list(flatten(ms))
4. These four files are part of a moderately large Python project
containing 80 modules.
According to how Phillip has described PEAK-style generic functions,
these assumptions are not at all unreasonable.
I am a new programmer analyzing the code on that project. I have read
the files flatten.py, mystring.py and bar.py but not foo.py. The
snippet in bar.py is then very surprising to me because it will print
['hello'] instead of ['h', 'e', 'l', 'l', 'o'].
Using a simple dispatch technique like the one in my handle_tok
example, or in the non-generic version of flatten, I wouldn't have
this problem. Now I do, so how do I troubleshoot it?
I could use the debug_it @before-function, but I don't think I should
have to just to see the control flow of a darn flatten function. The
other approach would be to grep the whole source for "flatten." Then I
should be able to figure out which dispatch rules are active when the
snippet in bar.py is invoked. But it would require considerable work.
--
mvh Björn
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
