Hi, @Chaoyingz
This implementation looks really clean and smart!
But I think I misled you by giving the example

I come up with another idea to make it implemented with less code (PRef may not be necessary. We just need to enhance the PFeature). Besides, the interface will more consistent (Using P to convert period time to observation time )
Chaoyingz#2

Looking forward to your comments about it

Hi, @you-n-g
I think PFeature should be a feature rather than an expression, no additional parameters should be added to the feature.
How about extending an existing P expression directly? For Example:
https://github.com/Chaoyingz/qlib/blob/fabdebd03d86a46b8cc62d3560fc599d034d48ea/scripts/data_collector/pit/test_pit.py#L211-L231

@Chaoyingz
I think both implementations are good enough but not perfect.

• The previous version will make PFeature more complex
• The current version will make load function more complex.

We are trying to introduce minimal complexity (fewer methods, fewer arguments in the interface) into the framework when adding new features.
Instead, if the complexity is added to a concrete subclass, it would keep the framework clean.

And I come up with another option just now. How about adding a subclass for PFeature which support an extra period argument? (e.g. changing PF to such a subclass from an alias)

I think all the above solutions are good enough. You can choose the one you like :)

@you-n-g
I think PFeature is a feature (corresponding to the file name), and P is an operator. If you want to build a feature dynamically, it is better to use an operator. So PRef is the better choice.

I think the next step should be to adjust PFeature to make it completely independent from P, let PFeature return the data first, and then the P operator or PRef operator to process the returned data, instead of giving him parameters when getting PFeature data.

Hi， @Chaoyingz
I agree with you
Please add more docs for load https://github.com/microsoft/qlib/blob/main/qlib/data/base.py#L157 to describe the period argument.

I think your next step looks very reasonable.
By such design, maybe the performance of PIT be boosted a lot.

@you-n-g 👌

It looks great!
Besides, 1000 is really a nice number :P