Generate ta-lib function definitions.

[ramazanpolat]

This module generates ta-lib function definitions along with docstrings. Generated .py file then can be used by developers more easily because of already provided function parameters and docstring.

Instructions:
1- Install ta-lib
2- Run tafungen.py
3- You will have a tafun.py file
4- Import tafun.py and use it happily.

Sample generated tafun.py file content:

from talib import abstract
def ACOS(inputs, price='close'):
"""
**Vector Trigonometric ACos**
Group: Math Transform
:param inputs: input values
:param price: price (**default**: 'close')
:returns: real
"""
return abstract.Function('ACOS', price=price)(inputs)
def AD(inputs, prices=['high', 'low', 'close', 'volume']):
"""
**Chaikin A/D Line**
Group: Volume Indicators
:param inputs: input values
:param prices: prices (**default**: ['high', 'low', 'close', 'volume'])
:returns: real
"""
return abstract.Function('AD', prices=prices)(inputs)
def ADD(inputs, price0='high', price1='low'):
"""
**Vector Arithmetic Add**
Group: Math Operators
:param inputs: input values
:param price0: price0 (**default**: 'high')
:param price1: price1 (**default**: 'low')
:returns: real
"""
return abstract.Function('ADD', price0=price0, price1=price1)(inputs)
def ADOSC(inputs, fastperiod=3, slowperiod=10, prices=['high', 'low', 'close', 'volume']):
"""
**Chaikin A/D Oscillator**
Group: Volume Indicators
:param inputs: input values
:param prices: prices (**default**: ['high', 'low', 'close', 'volume'])
:param fastperiod: Fast Period (Number of period for the fast MA - **default**: 3)
:type fastperiod: int)
:param slowperiod: Slow Period (Number of period for the slow MA - **default**: 10)
:type slowperiod: int)
:returns: real
"""
return abstract.Function('ADOSC', fastperiod=fastperiod, slowperiod=slowperiod, prices=prices)(inputs)
def ADX(inputs, timeperiod=14, prices=['high', 'low', 'close']):
"""
**Average Directional Movement Index**
Group: Momentum Indicators
Function flags: Function has an unstable period
:param inputs: input values
:param prices: prices (**default**: ['high', 'low', 'close'])
:param timeperiod: Time Period (Number of period - **default**: 14)
:type timeperiod: int)
:returns: real
"""
return abstract.Function('ADX', timeperiod=timeperiod, prices=prices)(inputs)

[mrjbq7]

Is this mainly for the Abstract API?

The Function API already has docstrings like this:

>>> help(talib.ACOS)
ACOS(...)
ACOS(real)
Vector Trigonometric ACos (Math Transform)
Inputs:
real: (any ndarray)
Outputs:
real

[ramazanpolat]

Yes. The docstrings are generated using Function class properties. But since the Function API generates it dynamically, it is inaccessible while coding, hence the generated code provides the necessary docstrings before compilation. That makes it easy to write code.

For example, with abstract API, we get this:

Also, docstrings are not available while coding:

Using the tafun.py generated by tafungen.py provides this:

And this:

That makes easy to use ta-lib functions.

[mrjbq7]

I wonder if we can change the abstract api to generate these docstrings automatically when it constructs itself, rather than using a wrapper module like this.

[ramazanpolat]

I wonder if we can change the abstract api to generate these docstrings automatically when it constructs itself, rather than using a wrapper module like this.

AFAIK that is not possible since dosctrings can't be provided dynamically.

[kmecpp]

This would be very helpful

[rokups]

Came here to propose such change. Would be great if this was accepted.

[rokups]

I updated and fixed the generator script so here it is: talibgen.py.txt

[mrjbq7]

I wonder if we can change the abstract api to generate these docstrings automatically when it constructs itself, rather than using a wrapper module like this.

AFAIK that is not possible since dosctrings can't be provided dynamically.

I think it is possible:

In [1]: def foo():
...: """
...: This is a docstring
...: """
...: pass
...: In [2]: help(foo)
In [3]: foo.__doc__ = "This is a different docstring"
In [4]: help(foo)

[ramazanpolat]

@mrjbq7
My solution puts docstring along with function parameters into generated function body, once this is done IDE will be able to read from that docstring when that function name is typed by the developer. Hence IDE can assist developer by auto complete because IDE already knows about parameters of the function and docstring. This is the idea behind generating functions along with proper parameters and docstrings.

Above I've said this:

AFAIK that is not possible since dosctrings can't be provided dynamically.

Actually it is possible to add docstring dynamically, but that won't help for code autocompletion.
In order to have code autocompletion, the IDE must see the docstring and parameters before you run the code. Hence providing a docstring dynamically won't help.

[mrjbq7]

Is the issue that the tools parsing files for doc strings aren’t able to handle a callable created dynamically with a correct docstring?On Apr 14, 2023, at 12:14 AM, Ramazan Polat ***@***.***> wrote: @mrjbq7 My solution puts docstring along with function parameters into generated function body, once this is done IDE will be able to read from that docstring when that function name is typed by the developer. Hence IDE can assist developer by auto complete because IDE already knows about parameters of the function and docstring. This is the idea behind generating functions along with proper parameters and docstrings. Above I've said this: AFAIK that is not possible since dosctrings can't be provided dynamically. Actually it is possible to add docstring dynamically, but that won't help for code autocompletion. In order to have code autocompletion, the IDE must see the docstring and parameters before you run the code. Hence providing a docstring dynamically won't help. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>