Live trade session

[ryankennedyio]

Minor refactor of the original backtest.py class to also allow for live trading. Live trading only differs in that it's "end-condition" is the passing of time, until and end_session_time. All loop logic remains the same.

This branch is a dependancy of https://github.com/mhallsmoore/qstrader/pull/186. I created a new branch here as the logic has no overlap with IB integration.

I'm suggesting we don't do the IBService setup/teardown in the TradingSession -- we must do it in the setup scripts where the user defines their strategy, symbols, handlers, etc.

Otherwise we need to create a TradingSession for each service, or create an abstraction where we take in a list of services (unnecessarily complex). As it stands, the TradingSession simply takes in a set of QSTrader components (price, risk, execution handlers, etc) -- each of these components may have services/external system dependancies, but the trading loop does not -and should not- care.

Would appreciate prompt integration with master so I can get cracking with live market data in the IB-PriceHandler

[coveralls]

Coverage increased (+0.04%) to 57.143% when pulling fdb7a55e09b112e2a43136cd539c9b54b459e87b on ryankennedyio:live_trade_session into ca05a06cf8429f571d566a39409f674142676af3 on mhallsmoore:master.

[femtotrader]

I wonder if such a class can handle

• backtest
• live trade
• but also paper trader (live price feed but simulated execution)

I really think that an abstract class AbstractTradingSession and 3 inherited classes BacktestSession, LiveTradeSession, PaperTradeSession is a cleaner approach.

But renaming simulate_trading method to start_trading (or simply start or run) is a good idea.

[mhallsmoore]

No problem - promptly done! ;-)

If you feel you need to change some of the logic in the previous (to this merge) Backtest object (which is now TradingSession), go ahead. I modified it to make the API cleaner, such that we didn't end up with these rather large ***_backtest.py files containing all of the instantiations of the respective components.

I'm definitely open to trying to find ways to make this simpler for new users, but at the same time extensible for those who wish to tinker a bit more.

[ryankennedyio]

Thanks @mhallsmoore

@femtotrader with regard to paper trade, don't all brokers offer a separate paper trading account ? I.e. from the system point of view, live is the same as paper?

I think even if we did do that, the trading loop logic should be the same; it's just the ExecutionHandler and Portfolio classes wouldn't have feeds to the broker for live execution/portfolio stats?

Just IMO more abstraction here probably isn't going to be used too often? I think we should have abstract base classes where we expect that users will implement their own inherited classes "fairly" often. I guess if we find people often need to override the trading sessions, we can add the abstraction in.