How about "pure virtual methods"?

Fredrik Lundh fredrik at pythonware.com
Sun Dec 19 12:58:40 EST 2004


Alex Martelli wrote:

>>     Traceback (most recent call last):
>>     File "mymodule.py", line 9, in somefunction
>>         someobj.bar()
>>         ... zero or more lines ...
>>     File "somelibrary.py", line 3, in bar
>>         raise NotImplementedError("must implement abstract method bar")
>>     NotImplementedError: must implement abstract method bar
>>
>> you have to look at the last line of a traceback to find the error
>> message, and the offending module/method is two lines above that.
>
> The offending module is the one which instantiates a class it shouldn't
> instantiate -- a class which isn't made concrete by overriding all
> methods which need to be.  What is that module?

in real life, it's mymodule.py or mylib.py, in code that you wrote very recently.

> The error is generally not the calling of 'bar' on someobj: someobj
> arrives as a argument to somefunction from somewhere -- the caller of
> somefunction is quite often innocent, in turn -- who BUILT someobj, by
> instantiating which class?  I think `minutes' is a very fair (not at all
> pessimistic) assessment of the time it will generally take to find out.

you can blather for years if you want to, but your arguments are just another variant
of the "you cannot use whitespace for indentation" stuff we've all seen from time to
time; it's trivial to come up with a large number of theoretical problems with any given
approach, but in real life, for real-life programmers, using real-life libraries designed
by real-life developers, it's simply not the problem you want it to be.

but not that I'm going to convince you, now that you've spent 15,000 characters on
this topic...

</F> 






More information about the Python-list mailing list