QTPy-Lib, a new algorithmic trading Python library

ranpo

ranpo

After getting some warming feedback about my previous library release (link), I've decided to also release QTPy-Lib, an algorithmic trading python library for trading using Interactive Brokers.

I've developed it after wanting a simple, yet flexible, python trading library that has a very small footprint and uses very little resources.

Yes, I know that the world probably don't need another backtesting/live trading library - I since like to know 100% of the code intimately :D, I have decided to write my own.

Anyway, I've been using it for my own trading for a while and it works for me.

I hope you'll find it useful :)

Code:
https://github.com/ranaroussi/qtpylib

Documentation:
http://www.qtpylib.io/en/latest/index.html

Cheers.
 
I actually thought about it... but then again, there are many open source libraries with similar names, and I've been calling it QTPy internally for almost a year (QTPy = Quantitative Trading Python Library) so I've decided to keep it and rename it to QTPy-Lib.
 
Hi ranpo,
Can you note the operating system and MySQL Server version that you use with QtPyLib? Just to try & minimize errors tried in other setups...I'm trying to run it in Win7 with MySQL Community Server 5.7, and there are issues coming up linking to database qtpy while running blotter.py
 
I've tested QtPyLib on *nix platforms with MySQL 5.5-5.7, but I know of a few people that are using Windows machine (not sure which version).

I've seen some cases where MySQL can only be reached via 127.0.0.1 and not via localhost (not sure why) so I would test that as well...

Lastly, if your MySQL is configured to listen on any port other than 3306 (default in QtPyLib), make sure to specify it:

Here are all the relevant MySQL settings available for the Blotter library:

blotter = MainBlotter(
dbhost = "127.0.0.1",
dbname = "qtpydb",
dbuser = "master",
dbpass = "blaster",
dbport = 3306,
...
)

LMK if this helped.
 
Hey ranpo, thank you for this info - yes, I experimented with the Windows default settings against those you posted, and got the problem resolved.

On a separate note, have you used any of these Python packages related to trading? If so, did you find any usefulness in them for your research and/or live trading?
- Pysystemtrade (member 'globalarbtrader' here on ET)

- High-Frequency-Trading-Model-with-IB

- bt

- Futures (simply-called)
 
Hi,

I'm not familiar with the last one you mentioned, but I got to play a bit with the first three.

I'm also a fan of Rob Carver's (@globalarbtrader) blog and I think his book is absolutely brilliant!

I've decided to write my own library for 3 main reasons:
  1. I wanted to have an always-running blotter that handles market data processing for all of my strategies, and also log tick and minute to a DB even when my strategies aren't running.
  2. I wanted an event based framework that can handle quote, order book, tick, volume, and time-based strategies.
  3. I wanted to know every single piece of the code :)
One place where QTPyLib is still lacking, IMO, is the analysis part. I have plans on including an analysis module that integrates with Jupyter Notebook and produces nicely formatted reporting and graphs.

A few more features that are on the roadmap are a much nicer dashboard for realtime monitoring and analysis, as well as an option to use Man AHL's Arctic for data storage in favor of MySQL.

Hopefully, I'll finish all of these by the end of 2016.
 
You've done great work thus far sir, I'm a big fan of what you've made available to everyone! Now if only I hadn't hired a programmer to scratch-build for connection to Rithmic's infrastructure, I could just kick back while you make a great package freely-available ;)

I'm also setting up a db for tick data, 2-3 months across 30 futures instruments, plus another 8 years of hourly bars. Did you have any bottlenecks in accessing MySQL before, hence the planned option for use of Arctic?
 
Thanks! Its a weird (but good) feeling knowing people are using my code :)

As for MySQL - since the usage for long term storage (data is basically pulled only when the algo starts) there shouldn't be any bottlenecks per se. Worst case scenario is that your algo will take a few more seconds to start.

That being said, as the database grows you will have to move to a cluster based setup - which can be a huge headache. A MongoDB cluster is still a headache but is somewhat easier to manage and move from server to server by non DB admins.

The easiest and most lightweight approach for people who aren't db admins and do not need lots of historical data, is to periodically empty old records from the database (all but the trades table). I may be adding an on-demand historical data download functionality (for non tick-data), so most use-cases should be covered.
 
Curious: what's the current storage capacity needed for your database(s)? Do you foresee the need to scale up and go with something in the cloud (be it for capacity or latency concerns), or do you set it all up on a home machine?

I'm looking to set up a rolling 3-month db of tick-level data for about 30 US futures, then several years' worth of basic 1-hour bars beyond that. And, about the same scheme for 20-30 stocks at some point later. From the AWS cloud solution looked at thus far, monthly cost gets into several hundred bucks pretty quick, mostly from the data exchange between the colo'd blackbox, and the db.
 
You must log in or register to reply here.
Back
Top