> I have not experimented with how using decorators would end up feeling and
> looking like to separate the handling of many such shared issues. But I
> suspect in this case decorators for such use may not be an ideal solution,
> for two reasons:
[...]

Yes, qp does have an existing pattern for "meta-data" on exportables which
could be used to accomplish the same thing. However, the accepted qp
practice puts the page structure/behavior in the exportable's
implementation, not its meta-data. A decorator just factors that out into
a common place.

> Plus, I think one decorator looks fine, two is also OK, but if one gets
> into requiring to stack several for each exported page, hmmn, I always
> found that somewhat unappealing.

I haven't run into a need for more than one (yet).

[...]

Gizmo is cool, but I'm just trying to develop a minimal means of factoring
out page structure/behavior on a page basis rather than application wide
and within the confines of qp, qpy and python 2.5; i.e. no additional
packages or modifications.

My goal in bringing this up is to gain some mind-share for the practice so
that I don't code myself into obsolescence in some future version of
qp/qpy.

Dave