I've updated the series of beginner level blog posts I did on how to get started using python with the IB API. Previously this used the third party swigibpy (a python wrapper around the C++ API). The updated series uses the brand new native python API. Enjoy! http://qoppac.blogspot.co.uk/2017/03/interactive-brokers-native-python-api.html http://qoppac.blogspot.co.uk/2017/03/historic-data-from-native-ib-pyhon-api.html http://qoppac.blogspot.co.uk/2017/03/streaming-market-data-from-native.html http://qoppac.blogspot.co.uk/2017/03/placing-orders-in-native-python-ib-api.html http://qoppac.blogspot.co.uk/2017/03/getting-position-and-accounting-data.html Hope they're useful GAT
Thank you. BTW on your blog I noticed you complained about IB not allowing simultaneous logons: " No multiple trading login You can only have be logged into IB in one place at a time. This means: It means you can't have a manual front end (see next section) open, perhaps to monitor your trades or do a little manual trading in another account. Unsolvable problem. " I don't know whether this is still relevant; but, in case it is: It's true that a user can log on only once. But an account can have several users, something you can set up in account management. When you do this, a second user id can watch what the first user is doing, and for example cancel their order - there is even a column in TWS that then shows the user id that submitted an order - "submitted by".
Nice. Why not publish another book? Heck, somebody should publish an IBKR Hacks Manual. Are computer training books within your domain? The Python for Finance book has grown into a an incredible franchise. I am assuming you have met the author, too.
I don't feel qualified enough to write this kind of book (I'm the original 'dummy' in the subject line of this post). Also these sorts of books don't sell well: too specialist. I think Mike Halls Moore has written e-books on this subject already. I'm currently finishing up a book actually but its on portfolio construction. Something I think I know about... GAT
1) THANK YOU. 2) My understanding is that the "new" IB Python API is in fact a Pythonic wrapper on C++. Is this wrong? I have not built anything yet, but have only shopped. I did FORTRAN ancient years ago, and have carried Lotus 1-2-3 joy into OpenOffice Calc, and was looking to build-or-strip-down a Java API to feed real-time data to the OO Calc spreadsheet where the magic happens. That's still more overhead than necessary, I think -- so I'm leaning towards a Java reader, with a Python wrapper to recreate the spreadsheet operations without the rest of the OO Calc overhead. (Thus, loading Java, C++, and then Python architecture to outperform OOCalc seems like missing the boat.) Thoughts? Am I way off?
AFAIK it is native python, but to be honest I don't really care as long as it is supported by IB. Personally I'd avoid programming a system in more than one language at a time - what you are proposing sounds insane if I'm being honest... GAT
All of the IB language APIs are implementations of handling the one and only real IB API which is its socket messaging protocol. So whatever you program it is always the same underneath: sending/receiving streams of characters between sockets. That's the only tangible thing that IB actually defines. Every programming language just has their own way of sending and receiving these same messages. The different language implementations are therefore just "reference" implementations of the real messaging protocol because IB don't actually explicitly define the underlying messaging protocol anywhere outside of their company other than in the code used in these implementations. To make this concrete, part of the message to request market data for EUR.USD fx rate is: "1" (this is the code equivalent to reqMktData "10" (this is an api version code defined by IB so they know the format of what's coming next) "1" (the user defined request id/ticker id for the market data request) "12087792" (the contract id for EUR.USD) "EUR" (the symbol) "CASH" (security type) "" (expiry is null) etc So the messages are just made of long sequences of characters like above (without the " and separated by 0s so it knows where one part ends). That means that anyone who knows the correct message formats for all outgoing and incoming messages could write their own language specific implementation if they wanted to.
That has seemed a logical conclusion to me for a long time, but this is the first I have seen it written down. BOY that would be lovely to know in detail. That's about all I'd need! The rest I'd learn as I go. "Just show me what you want to see and I'll get it there..."