[TIP] Is it kosher to subclass plugins?
jpellerin at gmail.com
Tue Jun 24 07:13:27 PDT 2008
On Mon, Jun 23, 2008 at 10:57 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Jun 22, 2008 at 5:49 AM, jason pellerin <jpellerin at gmail.com> wrote:
>> On Sat, Jun 21, 2008 at 4:32 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>>> So the plugin seems to be working (the doctest in question *is* run
>>> correctly), but I'm wondering about that 'conflicting option' message.
>>> Am I misusing something? I can provide my entire code if it will
>> When you subclass a plugin, you have to be sure *not* to re-register
>> the superclass's commandline options. For example, you must override
>> options() and must not call super(...).options(...) from your
>> options(). You need to register only those options that are specific
>> to your subclass; if none are, then your options() method should be a
>> no-op. Likewise for configure() -- you don't want to call super()
>> there either.
>> Other things might go wrong, too -- this isn't a use case I planned
>> for, unfortunately. So once the options/configure issues are worked
>> out we may have some more pop up...
> OK, thanks for your explanation. Should I then understand that
> plugins are never meant to be reused, and just copy the entire thing
> wholesale, rename it and start from there?
That won't help either, unless you rename all of the options. The
thing to do if you want to reuse some behavior is subclass. The option
handling is really the only difficult part, and the solution to that
is to first, make sure you aren't registering the same options by
registering only whatever options are unique to your subclass and
second, piggyback off of the superclass by consuming its options,
where relevant, in your configure() method. That is, if you want to
use the --doctest-tests option in your subclass, you should *not*
register it in options(), but you *should* reference it in configure()
(that is, look in the options object passed to configure for whatever
that option sets) to set your configuration or change your plugin's
> And there is no mechanism for customizing how the plugin
> behaves, since it internally hardcodes the finder, doctestcase proxy,
> etc (much like doctest itself hardcodes everything).
Definitely a design flaw. I'm open to suggestions for opening it up
and otherwise making what you're trying to do easier, if you have any.
More information about the testing-in-python