plone.alterego 3.0.0

Low level support for dynamic modules

Now you see it, it now you don’t!

This package defines a dynamic module type that lets you create objects in the dynamic module on demand.

Usage

To use this package, you should:

• Identify an appropriate parent module where the dynamic module will live.

• Ensure that plone.alterego.dynamic.create() is called with this module and a dynamic module name. Typically, you’d do this in the parent module itself, so that the dynamic module is instantiated as soon as the parent module is imported.

• Register a named utility providing IDynamicObjectFactory. The name should be the same as the full dotted path to the dynamic module. This utility will be responsible for creating the objects that inhabit the dynamicmodule.

Example

For a more fully-featured example, see the alterego.txt doctest.

Let’s say we have a generic content class that should get a unique interface for each instance.

>>> from zope import interface
>>> class IContent(interface.Interface):
...     pass
>>> class Content(object):
...     interface.implements(IContent)

>>> c1 = Content()

To create the unique interface, we will use a dynamic module. There is a helper method to make this easier. It takes a parent module and a name as arguments:

>>> from plone.alterego.dynamic import create
>>> dynamic = create('plone.alterego.tests.dynamic')

We can now import this module:

>>> from plone.alterego.tests import dynamic

To make objects on demand, we’ll need to register a utility that can act as a factory.

>>> from plone.alterego.interfaces import IDynamicObjectFactory
>>> from zope.interface.interface import InterfaceClass
>>> class InterfaceOnDemand(object):
...     interface.implements(IDynamicObjectFactory)
...
...     def __call__(self, name, module):
...         schema = InterfaceClass(name, (interface.Interface,), __module__=module.__name__)
...         setattr(module, name, schema)
...         return schema

This utility should have a name that corresponds to the full, dotted name to the dynamic module. This way, we can have different factories for different dynamic modules. We’d register this in ZCML like so:

<utility
    name="plone.alterego.tests.dynamic"
    provides="plone.alterego.interfaces.IDynamicObjectFactory"
    factory=".factory.InterfaceOnDemand"
    />

From this point forward, when we access an attribute of the dynamic module, the factory will be used:

>>> dynamic.IOne
<InterfaceClass plone.alterego.tests.dynamic.IOne>

Note that so long as the setattr() call above is executed, the factory is called only once. That is, you’ll always get the same object each time you access a given attribute of the dynamic module.

Changelog

3.0.0 (2026-05-07)

Internal:

• Update configuration files. [plone devs]

3.0.0a1 (2025-11-19)

Breaking changes:

• Replace pkg_resources namespace with PEP 420 native namespace. Support only Plone 6.2 and Python 3.10+. (#3928)

2.0.2 (2025-09-10)

Internal:

• Update configuration files. [plone devs] (6e36bcc4)

• Move distribution to src layout [gforcada] (#4217)

2.0.1 (2024-01-19)

Internal:

• Update configuration files. [plone devs] (237ff4c8)

2.0.0 (2023-04-15)

Breaking changes:

• Drop python 2 support. [gforcada] (#1)

1.1.6 (2023-04-15)

Internal:

• Update configuration files. [plone devs] (5623f8b3)

1.1.5 (2020-04-20)

Bug fixes:

• Minor packaging updates. (#1)

1.1.4 (2020-03-21)

Bug fixes:

• Minor packaging updates. [various] (#1)

1.1.3 (2018-11-21)

Bug fixes:

• Cleanup project level files (setup.py, .travis-ci.yml…) [maurits] [gforcada] (#2524)

• Initialized towncrier. [gforcada] (#2548)

1.1.3 (unreleased)

1.1.2 (2018-11-21)

Bug fixes:

• Update code to follow Plone styleguide. [gforcada]

1.1 (2016-11-01)

New features:

• Add compatibility with Python 3. [datakurre]

1.0.1 (2016-08-11)

Fixes:

• Use zope.interface decorator. [gforcada]

1.0 (2011-04-30)

• Use doctest from the stdlib instead of from zope.testing [davisagli]

1.0a1 (2009-04-17)

• Initial release.