[Python-3000] PEP 3124 - Overloading, Generic Functions, Interfaces, etc.
bjourne at gmail.com
Thu May 10 12:40:13 CEST 2007
On 5/10/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 5/9/07, Phillip J. Eby <pje at telecommunity.com> 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
from overloading import overload
from collections import Iterable
"""Flatten an object to its component iterables"""
def flatten(ob: Iterable):
for o in ob:
for ob in flatten(o):
def flatten(ob: basestring):
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
4. There is a fourth file, bar.py, which contains
ms = MyString('hello')
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.
More information about the Python-3000