[Python-Dev] proto-pep: plugin proposal (for unittest) (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Fri Jul 30 12:38:50 CEST 2010

On 30/07/2010 11:09, Tarek Ziadé wrote:

On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote: ...

The Plugin Class ================

A sometimes-more-convenient way of creating plugins is to subclass the unittest2.events.Plugin class. By default subclassing Plugin will auto-instantiate the plugin and store the instance in a list of loaded plugins. Each plugin has a register() method that auto-hooks up all methods whose names correspond to events. Plugin classes may also provide configSection and commandLineSwitch class attributes which simplifies enabling the plugin through the command line and making available a section from the configuration file(s). What about using ABCs here instead ? The big advantage is that you don't force people to subclass your Plugin base class,

Is that an advantage? Subclassing Plugin provides functionality rather than particularly an interface.

and you get a registration mechanism for free.

Actually it looks like it would be extra code. (The registration mechanism is already "free" to the programmer when they subclass.) I will investigate this, but if the only benefit it provides is "you don't have to subclass" then I'm not sure there is any point. Note that the Plugin class is only "sugar" over hooking up to the events directly anyway, so there is no need to use Plugin to write extensions.

I'm going to read your blog entry on the topic to evaluate it properly though:

https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-and-the-extensions-package/

Michael

They would be able to explicitly register any class using :

from unittest2.events import Plugin Plugin.register(MySuperPlugin)

Regards Tarek

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

More information about the Python-Dev mailing list