You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be worth making the pandas dependency optional, allowing users who define all their regular transaction frequencies in simple terms (e.g. "y", "m", "3m", "12w") to lose the dependency?
To give some context, beanahead also provides for defining regular transaction frequencies in terms of pandas frequencies.
Please +1 this comment, or add your own comment, if you only require simple frequencies and would like to be able to lose the pandas dependency.
What it would require
pandas is used by the rx_txns module to evaluate future transaction dates. This is implemented by way of creating a pd.offsets.BaseOffset which in turn is passed to pd.date_range.
For simple frequencies, e.g. "m", "13w", it would be pretty trivial to evaluate the future transaction dates without recurring to pandas:
if freq describes weeks the simply add a timedelta
if freq describes 'months' or 'years' then add months / years to datetime.date object, accounting for change in year if 'months'.
Why not drop the dependency?
I feel the functionality provided by being able to define frequencies as pandas frequencies is a worthy inclusion and I can't see it being practical to try and localize it - better to rely on pandas.
The text was updated successfully, but these errors were encountered:
Would it be worth making the
pandas
dependency optional, allowing users who define all their regular transaction frequencies in simple terms (e.g. "y", "m", "3m", "12w") to lose the dependency?To give some context, beanahead also provides for defining regular transaction frequencies in terms of pandas frequencies.
Please +1 this comment, or add your own comment, if you only require simple frequencies and would like to be able to lose the
pandas
dependency.What it would require
pandas
is used by therx_txns
module to evaluate future transaction dates. This is implemented by way of creating apd.offsets.BaseOffset
which in turn is passed topd.date_range
.For simple frequencies, e.g. "m", "13w", it would be pretty trivial to evaluate the future transaction dates without recurring to
pandas
:timedelta
datetime.date
object, accounting for change in year if 'months'.Why not drop the dependency?
I feel the functionality provided by being able to define frequencies as
pandas
frequencies is a worthy inclusion and I can't see it being practical to try and localize it - better to rely onpandas
.The text was updated successfully, but these errors were encountered: