IB API HOWTOs and Guidelines - For Beginners

sure and to back up your claims you can of course mention to all of us which large bank or asset management firm runs their OMS written in Python. You are delusional. I am willing to bet the farm that you either evade to provide firm backup or come up with some BS because I have been in this game way too long to know that there is nobody in their right mind who would write an OMS in python. And there are a million reasons for that. But before I get into that I first wanna hear some backup before wasting any more of my precious time.

Until then you made some outrageous claims re OOP languages and it is you who looks stupid based on the current status quo. Help us change our perception about you...

You are living in the past, yes my point is that OOP is being overused for a lot of things that shouldn't consider OOP. This has nothing to do about being serious, credible or anything, it's just a question of choice and programming habits. If you think that Python is not taking over Java or other OOP languages, then think again, it's coming now. Python is now replacing Java as the main learning programming languages in most US and European Engineering Universities. Not saying OOP will disappear, but it will no longer be the default programming style for business applications out there.

As for seeing a full OMS in Python, I have seen OMS and OMS related projects that are being ported to Python, projects by large Investment Banks with multi-million USD budget. Again, not sure why it's so incredible to consider it couldn't happen. Again for those living in the past, it surely can't happen.

As for "small changes" breaking code, maybe if you were working on large scale projects with hundreds of developers, you would get it. When you are working alone, those "small changes" are indeed your own responsibilities.

I don't think you have any authority here, or anywhere else for that matter, to claim my opinion about those programming techniques should automatically disqualify me or my credibility. You might not like or understand what I am saying, but that doesn't take away the facts I have mentioned above. You choose not to agree with them is your own personal choice and bias, not mine.
 
Until then you made some outrageous claims re OOP languages and it is you who looks stupid based on the current status quo. Help us change our perception about you...

I couldn't care less what your perception of me is, and I have no intention to persuade you otherwise,

and since when the status quo is a source of change ? never been, and you know it. This is just the beginning of change, I know that all those silly Java Applications Servers I have been working with in the last 15 years are going to disappear in the next 5 years for a number of technical reasons. Like I said, you can stay in the past or look into the future, and the future is not pure OOP and Java.

As for naming names, have you worked with every big corp in the Industry ? let me guess, no.

I know SocGen and BNP are working on those portage, of course they are not going to switch everything overnight but we are getting there. Still a work in progress.

Anyway, what's your beef with Python as this seems to be the main question here ?
 
if you are talking about trends and changes all of a sudden then I recommend you work on improving your English skills. So far your outcry about OOP reflected your opinion about the status quo. I can only repeat, your assessment that OOP languages are ill suited to OMSs is not only complete and utter nonsense. It also shows you do not even understand what OOP really means. Python, R, and a number of interpreted languages heavily borrow from OOP concepts and so it is not even sure what your gripe is. Certainly the status quo does not reflect that any major financial firm has so far much confidence in Python as a tool to develop major production stealth execution systems. And I do not see Python installed anywhere else than on quant developers' and quant strategists' desk. Get real!!!


I couldn't care less what your perception of me is, and I have no intention to persuade you otherwise,

and since when the status quo is a source of change ? never been, and you know it. This is just the beginning of change, I know that all those silly Java Applications Servers I have been working with in the last 15 years are going to disappear in the next 5 years for a number of technical reasons. Like I said, you can stay in the past or look into the future, and the future is not pure OOP and Java.

As for naming names, have you worked with every big corp in the Industry ? let me guess, no.

I know SocGen and BNP are working on those portage, of course they are not going to switch everything overnight but we are getting there. Still a work in progress.

Anyway, what's your beef with Python as this seems to be the main question here ?
 
and those are utter lies you put up. Neither BNP nor SocGen are working on anything that relates to Python at least not when it comes to execution related system. Guess what, both houses in fact completely re-wrote their code bases and retired their C++ code bases for all DMA execution related algorithms, for their derivatives pricing engines, front-office Excel plugins, and numerous others. Guess which language...C#. Nobody considers Python a serious contender to handle such monstrous tasks. Python was never designed to do that anyway. It was designed as a light-weight "glue" to patch together lose ends, to do some quick testing of algorithms. You may wanna read up on the origins of Python before you swing around with your little prick. Idiot.




I couldn't care less what your perception of me is, and I have no intention to persuade you otherwise,

and since when the status quo is a source of change ? never been, and you know it. This is just the beginning of change, I know that all those silly Java Applications Servers I have been working with in the last 15 years are going to disappear in the next 5 years for a number of technical reasons. Like I said, you can stay in the past or look into the future, and the future is not pure OOP and Java.

As for naming names, have you worked with every big corp in the Industry ? let me guess, no.

I know SocGen and BNP are working on those portage, of course they are not going to switch everything overnight but we are getting there. Still a work in progress.

Anyway, what's your beef with Python as this seems to be the main question here ?
 
Last edited:
you could try to submit a list of Contracts Objects to the IB Server on a given connection, but I doubt that would work. I suspect you would need to create several "connection" (different Client ID) to IB Server, with each connection (Client ID) corresponding to a Symbol you would like to retrieve the MktData from.

Again IB APIs might not be the best solution for Market Data feed. Their implementation seems to be limited, and there are reports of delays from the IB Server replies regarding accurate MktData.

Quote data feeds are best if they are implemented outside the IB APIs. You can still mix those implementation and the IB APIs in your code, but it won't be IB running the MktData part of your code.

There is a limit of separate connections to TWS - it is about maximum of 8 clients connected that can be handled by TWS.

You do not submit anything to IB server directly. It is done through TWS or Gateway.

The way to have multiple quotes updating up to maximum of 100 (unless certain conditions are met and this limit can be increased) is to submit 100 requests for market data usually done in a loop with different id (first field - just put some integer there different from previous request) and obviously with required contract information for desired symbol. This ID will be used when TWS returns quotes. This ID is user generated and has nothing to do with orderID - just put numbers 0 - 99 that would map to your symbol list.
 
and those are utter lies you put up. Neither BNP nor SocGen are working on anything that relates to Python at least not when it comes to execution related system. Guess what, both houses in fact completely re-wrote their code bases and retired their C++ code bases for all DMA execution related algorithms, for their derivatives pricing engines, front-office Excel plugins, and numerous others. Guess which language...C#. Nobody considers Python a serious contender to handle such monstrous tasks. Python was never designed to do that anyway. It was designed as a light-weight "glue" to patch together lose ends, to do some quick testing of algorithms. You may wanna read up on the origins of Python before you swing around with your little prick. Idiot.

oh oh, someone is an angry character and talking out of his arse, again.

you do not have access to every IT projects at BNP or SocGen, so how can you claim it's all lies ? maybe your own ignorance is being exposed here and you can't accept it.

Python is not about to "glue" anything, or being a small hack. Python is about simplicity and bringing back the fun of programming to developers instead of worrying about frameworks and other OOP non-sense.

and again you seem to confuse OMS with a lot of things. There are hundreds of OMS related projected that can be built with Python and are being built with Python. OOP and Java or inferior C# certainly do not have the monopoly on that market.
 
Last edited:
if you are talking about trends and changes all of a sudden then I recommend you work on improving your English skills. So far your outcry about OOP reflected your opinion about the status quo. I can only repeat, your assessment that OOP languages are ill suited to OMSs is not only complete and utter nonsense. It also shows you do not even understand what OOP really means. Python, R, and a number of interpreted languages heavily borrow from OOP concepts and so it is not even sure what your gripe is. Certainly the status quo does not reflect that any major financial firm has so far much confidence in Python as a tool to develop major production stealth execution systems. And I do not see Python installed anywhere else than on quant developers' and quant strategists' desk. Get real!!!

well at least I can speak several languages, can you ? probably not,

Python can do OOP you silly idiot, but it's not required. That's the beauty of it.

And what is it with your "Status Quo" thing ? you have no clue what's being done these days, you don't have access to every projects on the planet, so stop making silly claims about status quo, you have no fucking clue and it feels like you are trying to prove yourself by hiding behind some "invisible" status quo thing, like we should give a fuck about it.
 
you could try to submit a list of Contracts Objects to the IB Server on a given connection, but I doubt that would work. I suspect you would need to create several "connection" (different Client ID) to IB Server, with each connection (Client ID) corresponding to a Symbol you would like to retrieve the MktData from.

The way to have multiple quotes updating ... is to submit 100 requests for market data usually done in a loop.

Thanks for your answers.

My latest implementation simply loops over an array of symbols (1 client ID). I plan to extend it with a throughput constraint to avoid hitting the 50 messages per second limit - something I'm putting in place now. A delay of a few seconds for ~500 symbols is no problem for my needs.
 
Thanks for your answers.

My latest implementation simply loops over an array of symbols (1 client ID). I plan to extend it with a throughput constraint to avoid hitting the 50 messages per second limit - something I'm putting in place now. A delay of a few seconds for ~500 symbols is no problem for my needs.

apparently from the answers above, you can submit some kind of "id" to the IB Server for each contract MktData request, so the trick will be to manage and catch those IDs to keep track of the symbols and their MktData.

I do my symbol quote feed outside IB APIs, much easier. Not feeling comfortable having MktData and Order process going through the same MQ feed.
 
Back
Top