Closed HLasse closed 5 months ago
This issue is stale because it has been open for 14 days with no activity. Feel free to either 1) remove the stale label or 2) comment. If nothing happens, this will be closed in 7 days.
This issue is stale because it has been open for 14 days with no activity. Feel free to either 1) remove the stale label or 2) comment. If nothing happens, this will be closed in 7 days.
This issue was closed automatically. Feel free to re-open it if it's important.
This issue is stale because it has been open for 14 days with no activity. Feel free to either 1) remove the stale label or 2) comment. If nothing happens, this will be closed in 7 days.
@MartinBernstorff are you on board with inlining the type aliases? As we discussed, it makes it easier for the user, but a bit less nice for developers. I think it's a worthy trade-off in this case, though
I'm uncertain how many type-aliases will be inlined.
It does make me a little uncomfortable that types which are supposed to be the same can drift from one another.
If you have a strong opinion, I'm OK with that 👍
I've added a quick PR (#564) for the types outlined above to get a feel for how it would look. Some of the types were only used in one place, but I completely get the worry that more widely used types can potentially drift. It does it make it substantially easier for users, though. Have a look and let's talk about it at some point
This issue is stale because it has been open for 14 days with no activity. Feel free to either 1) remove the stale label or 2) comment. If nothing happens, this will be closed in 7 days.
E.g.
init_df
ofValueFrame|TimestampValueFrame
takes anInitDF_T
which is hard to parse without a doc string specifying it or by changing the type to be human readable.Others:
LookDistances
(sequence of dt.timedelta)