Why are there so many ways to access lines data?
After reading all Backtrader docs, one significant pain point is that there are too many ways to access internal lines data:
- self.dataclose = self.datas.close keeps a reference to the close line.
- self.data targets self.datas
- self.dataX targets self.datas[X]
- self.data_name offers a direct access to self.data.lines.name
- self.lines points to self.lines.sma
- self.line points to self.lines
- self.lineX point to self.lines[X]
- self.line_X point to self.lines[X]
- self.dataY points to self.data.lines[Y]
- self.dataX_Y points to self.dataX.lines[X]
- The operator () can be used as shown above with delay value to provide a delayed version of a lines object.
Oh no, this is not pythonic, There should be one-- and preferably only one --obvious way to do it.
Anyone has the same feeling with me?
run-out last edited by
I have to agree with your point. I do think the author was trying to provide options so intentions are all good. For me personally quite some time ago I decided to just stick with the formal self.datas which works under all conditions.
i have some mixed feelings about this. At the begin, when i did not know backtrader that much, it was confusing. But after getting into backtrader, they can handy. In most cases i ommit shortcuts and just access the lines without using the shortcuts.
Sometimes i use shortcuts:
- having a simple strategy with just one datafeed, i use self.data
- For params, i prefer using self.p
- For lines, either self.lines or self.l
on the other hand, for example, when debugging, the objects have a lot of different lines, which makes it harder to find the stuff you want to look for. It makes code harder readable if you don't follow some coding rules, even for yourself. The more possibilities there are, the more you can do wrong.
Basically, i can see @soulmachine point, but it does not really bother me having them there. Also I wouldn't mind, if there would be just one defined way to access it. It could be, that there are usecases, where they were needed.
@soulmachine there is no statements explicitly syaing
There should be one-- and preferably only one --obvious way to do it.
in that list. But I can see how your statement can be in disagreement with the number of the items in that list. And reading thru that list I can see that you set more limitations on yourself, thatn that guy applied.
For example: if you always backtest and trade only one data feed, than it is simple, and beautiful, and readable, and practical (Python Zen wording :) ) to use
vbs last edited by
I also think having multiple names for the same thing is quite confusing. I would love seeing bt/bt2 just decide for one wording and be consistent with it. I actually think
datasmight be the only duplication I might see a benefit in.
I also think having multiple names for the same thing is quite confusing. I would love seeing bt/bt2 just decide for one wording and be consistent with it. I actually think data and datas might be the only duplication I might see a benefit in.
In backtrader2 it would also be nice to get rid of meta programming, this feature is prohibited in Google Python Style Guide
run-out last edited by
At this point the main objective of Backtrader2 is to provide a place for bug fixes to be merged into a working copy and also allow for minor enhancements. Changing the fundamental structure of the program to meet a style guide is not something that is likely to happen at this time.