[ENH] Refactor the `data_module` layer in `ptf-v2`

[phoeenniixx]

Is your feature request related to a problem? Please describe.
For now the EncoderDecoderTimeSeriesDataModule code is a little messy, that contains a nested dataset class (_ProcessedEncoderDecoderDataset) and preprocessing and splitting functions. It makes the code a little hard to understand and maintain as we move to more complex implementations

Describe the solution you'd like
We should make it more modular:

• Move the nested _ProcessedEncoderDecoderDataset class out of the data_module class.
• Create separate modules for preprocessing and splitting etc
• Call references of these implementations in the data_module class

This will make the code a little more clean and modular and easy to maintain.

Additional context
Please look at how the tsl handles these splitting and preprocessing using different modules

[phoeenniixx]

FYI @agobbifbk, @fkiraly , @PranavBhatP

[PranavBhatP]

Hi, @phoeenniixx, after going through the code for the EncoderDecoderDataModule, I did notice that many parts of this module are reusable and can be adapted for usage by other implementations of data modules for v2.0, so I think it's a necessary step to do this early on before we introduce a lot duplication in code.

[fkiraly]

I did notice that many parts of this module are reusable and can be adapted for usage by other implementations of data modules for v2.0, so I think it's a necessary step to do this early on before we introduce a lot duplication in code.

Interesting. I think it could be instructive if you try to draft this in a hacky way, but then we do not merge this but take this as a study motivating a clean refactor.
Does #1830 already do this, or is it only the case for non-decoder/encoder models?

[fkiraly]

Another point I noticed why finalizing #1811 is that you the loaders and data modules are not dataclass-like, i.e., some __init__ arguments get mutated through coercions or defaults.

It is general best practice to make specification-like classes also dataclass-like, so I tried to move the processed attributes to private versions, but this causes test failures. So instead, I did that and then I added overwrites in "todo" sections in the __init__ so the code does not break.

My question would be, how much problems does it cause if we try to make the modules and loaders dataclass-like? Is it just a matter of changing tests, or would we be changing a public contract that you had in mind, @phoeenniixx?

[phoeenniixx]

My question would be, how much problems does it cause if we try to make the modules and loaders dataclass-like? Is it just a matter of changing tests, or would we be changing a public contract that you had in mind, @phoeenniixx?

yes, ig all we need to do is just make some changes to tests and code and it will become dataclass-like :)

[fkiraly]

yes, ig all we need to do is just make some changes to tests and code and it will become dataclass-like :)

I prepared it in a way that you just need to delete the "todo" blocks in each class - but I was worried it would break some implicit contract that you had in your head. It certainly breaks the tests.