finplot seems to be a great package. pity that it does not work in Jupyter Lab. As this far, all my work are done in jupyter lab. For charting, I copied some code from backtesting.py for auto-scale(JavaScript which I do not know) and use bokeh together to plot a candlestick chart.
A Semi-automated system with Python and IB api
- Thread starter Warren
- Start date
finplot seems to be a great package. pity that it does not work in Jupyter Lab. As this far, all my work are done in jupyter lab. For charting, I copied some code from backtesting.py for auto-scale(JavaScript which I do not know) and use bokeh together to plot a candlestick chart.
I checked a bit into the pyqt documentation and most of the UI elements appear absolutely basic at best. If that works and is sufficient for a project then that's all that is needed.
But usually the requirements are way higher for a decent UI frontend. Just a single example: a grid control. What if new content is published onto the grid (or added to collections that bind to that grid and the user wants the UI to autoscroll to the last row if the previously last row is visible, and not autoscroll else. What if upon selecting a row some event should be triggered? What if I wanted to multi select and drag multiple rows onto a different grid control? Those are just some very basic requirements a UI library should consider. What about performance when creating a chart with 10000 data points on the chart in pyqt? What about user interaction? Is panning, zooming, selecting all seamless even with larger data collections.
Again, the above might not be what everyone requires but it's nonetheless a good subset of features to compare different integration environments. I see all too many evangelists here who hark back and forth about language and OS choices, or how adding additional language capabilities would make an implementation "very nicely transparent" when the most important part of a project is to solve a specific set of problems. That's where developers often times get stuck and where project managers (hopefully) have more visibility. For someone who works for himself or herself both, keeping the solving of a problem and the implementation, in mind at the same time is essential. Too many get lost in language or style choices before they have figured out a way how to solve the problem.
But usually the requirements are way higher for a decent UI frontend. Just a single example: a grid control. What if new content is published onto the grid (or added to collections that bind to that grid and the user wants the UI to autoscroll to the last row if the previously last row is visible, and not autoscroll else. What if upon selecting a row some event should be triggered? What if I wanted to multi select and drag multiple rows onto a different grid control? Those are just some very basic requirements a UI library should consider. What about performance when creating a chart with 10000 data points on the chart in pyqt? What about user interaction? Is panning, zooming, selecting all seamless even with larger data collections.
Again, the above might not be what everyone requires but it's nonetheless a good subset of features to compare different integration environments. I see all too many evangelists here who hark back and forth about language and OS choices, or how adding additional language capabilities would make an implementation "very nicely transparent" when the most important part of a project is to solve a specific set of problems. That's where developers often times get stuck and where project managers (hopefully) have more visibility. For someone who works for himself or herself both, keeping the solving of a problem and the implementation, in mind at the same time is essential. Too many get lost in language or style choices before they have figured out a way how to solve the problem.
Oh, one other thing I forgot in my prior post. If you want to be able to run your code across the 3 major OSes, like the idea of prototyping in Python but may eventually want a faster, more polished version in C++, another suggestion is to use Dear PyGui for Python and then Dear ImGui for C++. ImGui is built on top of multiple graphics rendering backend (seamless to choose which one you want) so the GUI is not going to be native to the respective OS but contains a lot of the essential elements you would expect.
A plus to starting with this is that there's a nice plotting contribution called ImPlot which has a demo app of a candlestick chart that can fully pan, add indictators, plot X and Y axis info, etc. Dear PyGui comes bundles with ImPlot.
My preference would be to stay on the Python side. That side is taking the immediate mode graphics lower layer from imgui and putting a retained mode layer (i.e. callbacks for state changes) on top. The main DearPyGui developer is working full-time (at least he was last time I checked) on Patreon contribs.
https://github.com/ocornut/imgui
https://github.com/epezent/implot
https://github.com/hoffstadt/DearPyGui
https://github.com/hoffstadt/DearPyGui_Ext
https://github.com/Pcothren/DearPyGui-Examples
Well, I guess it is because many traders here are from a programming background.
At this moment, I am working on bokeh server to get the IB real time streaming data plotted on a candlestick chart. And I am quiet pragmatic: as long as the code can realize what I need, I do not care how this is done. Sticking to Python, no more learning of language.
It is the trading not programming that I am interested in. And I want to start paper trading, as soon as possible.
A second addendum to my original post:
If you'd like to stay with C# and you enjoy programming in WPF, there is now a cross-platform solution across the three major OSes which is WPF-like. It's called Avalonia:
https://avaloniaui.net/
An added bonus is that you can also have your apps run on iOS and/or Android (plus, not to forget the C# library for trading with IB is available [by IB]).
Fun stuff.
If you'd like to stay with C# and you enjoy programming in WPF, there is now a cross-platform solution across the three major OSes which is WPF-like. It's called Avalonia:
https://avaloniaui.net/
An added bonus is that you can also have your apps run on iOS and/or Android (plus, not to forget the C# library for trading with IB is available [by IB]).
Fun stuff.
The underlying platform is Maui. Devexpress offers quite well designed Maui based controls that are native multi platform.
https://platform.uno/wpf
I've just tried the uno platform on Ubuntu and it works. Another choice to develop for Linux if you are familiar with WPF.
I've just tried the uno platform on Ubuntu and it works. Another choice to develop for Linux if you are familiar with WPF.
Some recent experience to share(1):
Tossing around with IB's native package ibapi and the third party package ib_insync these days. Like people said, IB's native api has a very steep learning curve. While I am still determined to use ibapi from the beginning. The consideration is mainly about maintenance: some well coded third party package are very popular, but abandoned after some time. For example, the popular backtesting package in python, backtrader, has not been updated for a long time.
BTW, now, IB does offer Level I tick by tick data corresponding to the Time & Sales window in TWS. The trick is to make a request through reqTickByTickData() method in the EClient and retrieve these ticks through
tickByTickAllLast() method in the Ewrapper.
Two concept worth borrowing from the ib_insync: Events() and maybe asynchronous programing in the future.
Now I consider two kinds of 'events': 1) when a new tick data is received, plot it on the chart, and check whether there is unexpected very large loss; 2) when a 'minute' is finished, plot a new bar, calculate all the indicators, check whether entry rule is triggered, etc. The trick is to emit an event in ibapi's EWrapper method, and process all the data some where else.
Any idea is welcomed. How did you get similar things done. Everyone has his own needs, but better not to reinvent the wheel.
Warren.
Tossing around with IB's native package ibapi and the third party package ib_insync these days. Like people said, IB's native api has a very steep learning curve. While I am still determined to use ibapi from the beginning. The consideration is mainly about maintenance: some well coded third party package are very popular, but abandoned after some time. For example, the popular backtesting package in python, backtrader, has not been updated for a long time.
BTW, now, IB does offer Level I tick by tick data corresponding to the Time & Sales window in TWS. The trick is to make a request through reqTickByTickData() method in the EClient and retrieve these ticks through
tickByTickAllLast() method in the Ewrapper.
Two concept worth borrowing from the ib_insync: Events() and maybe asynchronous programing in the future.
Now I consider two kinds of 'events': 1) when a new tick data is received, plot it on the chart, and check whether there is unexpected very large loss; 2) when a 'minute' is finished, plot a new bar, calculate all the indicators, check whether entry rule is triggered, etc. The trick is to emit an event in ibapi's EWrapper method, and process all the data some where else.
Any idea is welcomed. How did you get similar things done. Everyone has his own needs, but better not to reinvent the wheel.
Warren.
Great thread. For me, there is no reason not to use python and get all the python data science tools for free. Pandas came about as a way to easier work with market data.
Bokeh is perfect for juypter lab. Seaborn is amazing too.
I love Jupyter but version control gets really annoying. I think at some point you would want to use Git. I always start in jupyter but end up using just a plain .py file so Git can track if I screw something up.
I have clunky system of a python backend and react front end with interacting through FastAPI. For me it is just too much effort and drudgery to automate anything under a minute time frame and anything beyond me manually entering the trades. To me, that is when you really start pealing the onion.
Bokeh is perfect for juypter lab. Seaborn is amazing too.
I love Jupyter but version control gets really annoying. I think at some point you would want to use Git. I always start in jupyter but end up using just a plain .py file so Git can track if I screw something up.
I have clunky system of a python backend and react front end with interacting through FastAPI. For me it is just too much effort and drudgery to automate anything under a minute time frame and anything beyond me manually entering the trades. To me, that is when you really start pealing the onion.
Last edited:
"clunky" and stitched together describes it well. Python in finance is a great research and analytical tool but there is a reason that virtually every trading architecture at hedge funds and banks is written in OOP languages. If you look for something truly algorithmic then python is most definitely the wrong tool. But hey, python can't be beat to whip up something quick.