v2 BacktestEngine: support add_strategy(instance) alongside add_strategy_from_config

[wayneadams]

Context

In the v1 (Cython) BacktestEngine, there are two ways to register strategies:

• Low-level / instance-based: engine.add_strategy(my_strategy), where you pass a constructed Python object directly
• High-level / config-based: ImportableStrategyConfig with BacktestNode, where you pass a dotted import path and a config dict

The v2 (Rust/PyO3) BacktestEngine currently exposes only add_strategy_from_config and add_actor_from_config. The instance-based add_strategy(instance) and add_actor(instance) are not available.

I'd like to ask whether adding instance-based registration to the v2 BacktestEngine is something you'd consider, and whether it fits the v2 design direction.

Use case: optimization and walk-forward loops

My project generates randomized strategy configurations (entry signal trees, exit parameters, reversal bar settings), runs single-day backtests in a loop, and archives trade-level results. A simplified version of the loop looks like:

for day in trading_days:
    engine = BacktestEngine(config)
    engine.add_venue(...)
    engine.add_instrument(contract)
    engine.add_data(ticks)

    # Construct actor and strategy with complex Python objects
    actor = BetterReversalActor(actor_config)
    strategy = ConstansoStrategy(strategy_config)

    engine.add_actor(actor)        # <-- not available in v2
    engine.add_strategy(strategy)  # <-- not available in v2

    engine.run()
    # extract results...
    engine.dispose()

The strategy configs contain nested Python objects (condition trees, indicator instances shared between signals) that are awkward to serialize through a dict to JSON to reimport round-trip on every iteration. In this kind of single-workstation optimization pattern, the strategies are constructed in the same Python process that's running the engine, so there's no need to serialize across a process or network boundary.

What I think is involved technically

Looking at the v2 implementation in crates/backtest/src/python/engine.rs, add_strategy_from_config does three things:

1. Import and construct the Python strategy object from a dotted path and config dict
2. Extract and configure the PyStrategy wrapper, including setting the strategy ID, logging flags, and storing the Python instance reference
3. Register with the trader by creating a clock, registering with cache/portfolio, and setting up event subscriptions

Steps 2 and 3 don't depend on how the Python object was created. They just need a Python object that inherits from PyStrategy. An add_strategy method could skip step 1 and go straight to step 2 with a caller-provided object.

The same applies to add_actor_from_config and PyDataActor.

Questions

1. Is instance-based registration something you'd consider being PR'd into the v2 BacktestEngine?
2. If not, how would you approach the optimization loop use case where strategy configs involve complex nested Python objects that don't lend themselves to dict serialization?

Thanks for the incredible work on the Rust port. The v2 build and type stubs are already a huge improvement!