• could you move this to datatypes.adapters?

I don't see this in the repo. Can you help me locate it?

• a back-conversion function would be nice, we need that for forecasts, do we not? Maybe a separate PR

Yes, this will be in a separate PR. That one is in progress.

I don't see this in the repo. Can you help me locate it?

It does not exist, sorry for being unclear - I suggest creating a new submodule, so we can isolate soft dependencies there.

• remove dependency on convert_to and check_is. I'll integrate it into the conversion framework later. Assume the input is pd-multiindex.
• do you need to input frequency? Can that not be inferred from the pandas input time index? This should be inferred and appropriately translated, instead of being overwritten, in the vanilla call.
• could you move this to datatypes.adapters?
• a back-conversion function would be nice, we need that for forecasts, do we not? Maybe a separate PR
• can you kindly add tests please, with example input and outputs?

• I use convert_to because the code works with nested pd.Series. If I remove convert_to, I will have to write my own code somewhere in the function that will do something similar.
• Frequency and start_date are now inferred from input data.
• The converter has been moved to datatypes._adapters
• Lastly, I am still working on making a pytest...

Lastly, I am still working on making a pytest...

I can help with the testing, there is a conversion testing framework already in datatypes. What it needs are examples that are the same in the format - so you could add examples to the panel._examples module?

Lastly, I am still working on making a pytest...

I can help with the testing, there is a conversion testing framework already in datatypes. What it needs are examples that are the same in the format - so you could add examples to the panel._examples module?

I added 2 examples: 1 for univariate and 1 for multivariate. Also added listdataset into registry. I'm still trying to figure out pytest

This is for my information only. After adding datatypes example, encounter
` def test_check_metadata_inference(scitype, mtype, fixture_index):
"""Tests that check_is_mtype correctly infers metadata of examples.

    Parameters
    ----------
    scitype : str - scitype of fixture
    mtype : str - mtype of fixture
    fixture_index : int - index of fixture tuple with that scitype and mtype

    Raises
    ------
    RuntimeError if scitype is not defined or has no mtypes or examples
    AssertionError if example metadata is not correctly inferred
    error if check itself raises an error
    """
    # retrieve fixture for checking

  fixture, _, expected_metadata = get_examples(

        mtype=mtype, as_scitype=scitype, return_metadata=True
    ).get(fixture_index)

E TypeError: cannot unpack non-iterable NoneType object

fixture_index = 1
mtype = 'listdataset'
scitype = 'Panel'

sktime/datatypes/tests/test_check.py:153: TypeError

for the record, this is as we discussed today in person:

the _examples are of a form where every "abstract example" should be spelled out in each of the mtypes. These should either be None or some data container. You added examples with index 3 and 4, so those are not available in the other mtypes.

A secondary question I have is how we deal with mtypes that have soft dependencies, I need to think about that more carefully.

@TNTran92, I´ve thought about this. Given the complexity of some design questions, see #2957, I would suggest:

Let´s separate this PR from the datatypes testing framework., i.e., split off the _examples and possibly _registry.

I would recommend to:

• put the examples and tests in a sub-folder of _adapters. Don´t try to integrate with the current test system, just make new tests with expected input/output pairs.
• then, focus next on the back-conversion, while we think about [ENH] How to deal with mtypes that have soft dependencies? #2957 and integration with the current testing framework (the soft dep question needs to be addressed first).

That would prevent us from getting stuck, and allows @AurumnPegasus to use the conversions already for gluonts neural networks.

(this is nothing related to the quality of your work - great work! This is only about removing a conditionality on integration to give @AurumnPegasus access to the functionality, and delaying the integration to a later piece of work)

Understood. I will try to get the unit test and the back-conversion done as soon as possible.

I have merge conflict that can't be resolved on this branch, so I will be closing this pull request and add the unit test plus everything done so far to the PR #2976