Afaik, there were no prior efforts of getting real, live trading in. I guess _Broker is certainly to be overridden. Just please do base your findings upon #47 as I do eventually intend to get that in.

after furthur study, I think practical approch is to mirror backtesting.py to a realtrading.py file (not disturbing original backtesting.py), still share Strategy class from backtesting.py. Backtest class, _broker, position need rewrite in new file, order/trade not sure as of now, probably keep as mirror of trade serverside data. No obvious barrier seen now for the real trade implementation(very broker API specific) :-)
The way of passing dynamic data into _broker,strategy using a _Data class is really smart , will copy the method in the realtrading.

I envision live trading by way of a separate class, in Python type notation, say:

from typing import Type, Union, Literal, NoReturn

LiveTrade(strategy: Type[Strategy],
          period: str,
          broker: Union[Literal["ib", "oanda", "ccxt"], Broker],
          **kwargs) -> NoReturn

The idea is we can reuse the same Strategy (hence we must adapt the _Broker), we must provide the trading cyclic period which to call Strategy.next() on (should likely match the period in bars of backtested-on data), and the chosen broker backend (here a string, mapping to each standalone class internally). Extra kwargs (a list of instruments, margins, and such) would be passed to the broker.

The common broker API is sure in the domain of its implementer. 😄

@kernc This needs some support, there has to be an abstract base class for live trading so that people can implement the Brokers of their choice as they like and ccxt library( for Crypto ) support as an example.

cc @ttfreeman Tagging you in case you are interested.

@arunavo4 Yes, definitely interested, though need to research on the best way to tackle this prior to diving in. I like @kernc 's suggestion to have a separate class (LiveTrade) but we might also need another class (LiveData) that would bridge the live data from broker to LiveTrade class.

feed=LiveData(....init params)
feed.connect(localhost, 567, ...)

LiveTrade( feed.data,
             strategy: Type[Strategy],
             period: str,
             broker: Union[Literal["ib", "oanda", "ccxt"], Broker],
             **kwargs) -> NoReturn

Data acquisition can surely be handled by the chosen broker (i.e. Broker)? Broker implementations should take their configuration parameters from **kwargs.

practically my current process to live trading is rewrite strategy ( slight modification - thanks to the backtesting's clear structure and pandas compatible data carrier) , to fit in live broker/data source. Building a BT compatible live trading framework is not a small project - considering BT is single equity, single datafeed( though resample applicable) , while trading is diversified. Now I use backtesting.py to verify my alorithm( or subset of algo) which works pefectly.Then write trading in a flexible way.
ps. I give up portion buy/sell in BT, in real world(trading), broker has no percentage trade API, strategy is responsible of calculating target buy/sell volume, also 'cause calculation for buy-open/sell-open/buy-close/sell-close volume and margin is too complicate for me.

I'd recommend keeping data feeds and brokers separate responsibilities. That way theoretically one could subscribe to any data source then execute trades with the broker of their choice without being tightly coupled to anything.

Definitely agree that having a path for people to BYOB (broker) is the way to go. Then strategy.buy() or strategy.sell() is executed on their broker of choice, even if it is a backtest broker.

Has anyone started work on this (that's shareable)?

@crazy25000 Have started working on it. but it's very integrated into my project. The gist is that we can easily (maybe not too easy) Make a class Similar to Backtest. Which can have Corresponding Broker Classes like CCXT/ Oanda/ Alpaca.

Waiting