Back

Calling Python Experts - Proposed New QC Python API

We want QuantConnect to be a truly multi-language platform - where language is not a barrier to writing quant strategies. Currently our Python API follows the C# method and variable names -- which is a little counter intuitive for python programmers.

To fix this we started a project to provide a 'pythonista' style to the API, trying to follow the patterns and capitalization python programmers are familiar with. Its been a few months work but its almost complete and we'd love to get your feedback -- please see the two comments below and vote to pick your favorite.

Comment 1 - The current style which follows the C# API.
Comment 2 - The proposed style using python style conventions.

Please vote on the comment style you like best!
---

Update Backtest






The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.



It does really matters, what would be the point in creating a python API if it will look like another language. To make it intuitive to Python programmers it should look like python code.
0

I feel like a lot of people are perhaps missing the point. They aren't "creating" a new Python API. The Lean implementation is accessed via IronPython's dotnet integration http://ironpython.net/documentation/dotnet/

More than likely what they are proposing is some wrapper API that hides this detail. Of course Python developers, of which I count myself, are going to want the proposed API but it doesn't change the fact underneath your code is calling C# code.

If I was writing something unrelated to QC that integrates with .NET framework classes (e.g a winforms app) I wouldn't expect the imports/API to differ and in fact they don't.

I appreciate that the QC team is trying to make this more accessible and familiar to Python developers but I just don't see enough benefit in maintaining some wrapper API (even if it can be auto-generated) just because the style differs.

QC team feel free to correct me if I've made an incorrect assumption somewhere.

0

Aaron, from an engineering standpoint you're probably right. But what you seem to be missing is that adoption by the Python community is a MASSIVE benefit. Not a technical benefit, but a social one (look at Quantopian for instance). 

0

Aaron is correct. It will be a auto-generated wrapper.

I do not want to believe that python coders are not coming to QuantConnect because of its API. We do have benefits over other platforms that should be more important than style.

Nonetheless, we want to provide this API to make people "feel at home".
The point of this thread is: "Do they care and/or want it?".
 

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


@Aaron you're right, technically that is the implementation. Like other decisions we make regarding the LEAN stack though we try to make the right decision regardless of difficulty which is why we started this wrapper project. From your detailed analysis though it looks like there are no good ways to support Numpy/Panda - either fix IronPython or create a raw python api using ZMQ messaging to talk to LEAN. Personally I like how IPy compiled dll's run lightening fast so lean towards that solution. 

Ultimately we want LEAN-Python to support all the built in libraries; so regardless of the API we have some thinking to do. The best course now is probably to spend more time seeing if IronPython can support Pandas/Numpy/SciPy - then continue the wrapper project. 

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


@Alexis Adoption and the underlying reason was not lost on me, as a

developer I understand and appreciate the tradeoffs they are making though.



@Alexandre, absolutely that is partially my point, the style makes little

difference, the capabilities are more important.



@Jared Yes, I can appreciate that, I don't mean to derail the conversation

either since the point of this thread was to simply take a vote, so

apologies. I was just trying to make sure everyone understood why the

current API looks the way it does and it wasn't a choice between creating

it one way or another necessarily. To your point maybe that isn't their

concern and if offering a Python API is possible and people want it then by

all means. And yes I would agree figuring out the numpy/pandas/scipy

integration is perhaps more important to people but that's a whole

different problem.



Anyway to hopefully put the thread back on track my vote is to keep it the

way it is ala C#.
0

I find the capital letter on method calls a bit annoying, I like the second style better: https://www.python.org/dev/peps/pep-0008/#function-names

Then on placing order the method  MarketOnOpenOrder was not really clear to me. Maybe a name improvement. Is it placing an order as Market?

0

Hi Lucas,

In the new style, MarketOnOpenOrder would be called market_on_open_order. The style wouldn't make it clearer for you, right?
The name logic is the following: order is the substantive and market on open is the adjective. It is a market on open, since it will be executed when the exchange opens at the market price of the security. I think it would be too wordy to call it MarketOnExchangeOpenOrder.

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Thank you all for the feedback. Lets call the discussion paused for now until we can resolve a way of getting the science/math libraries to talk to C#!

0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Update Backtest





0

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by QuantConnect. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. QuantConnect makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances. All investments involve risk, including loss of principal. You should consult with an investment professional before making any investment decisions.


Loading...

This discussion is closed