Improve ludwig feature dict

[dennisrall]

Some minor improvements to the LudwigFeatureDict:

• remove strange __next__ method
• remove internal_key_to_original_name_map dict as the values were never read
• use MutableMapping from the collections.abc → get useful and more performant methods
• added tests for the new functionality and split up the old test (I kept the old test to show it is still running, but I think it can be removed?)

[github-actions]

Unit Test Results

  4 files   -   2    4 suites   - 2   2m 58s ⏱️ - 11m 42s
12 tests ±  0    6 ✔️  -   3    5 💤 +2  1 ❌ +1 
40 runs   - 20  16 ✔️  - 26  20 💤 +2  4 ❌ +4 

For more details on these failures, see this check.

Results for commit acfa198. ± Comparison against base commit 0a24d0a.

This pull request skips 2 tests.

tests.regression_tests.benchmark.test_model_performance ‑ test_performance[ames_housing.gbm.yaml]
tests.regression_tests.benchmark.test_model_performance ‑ test_performance[mercedes_benz_greener.gbm.yaml]

♻️ This comment has been updated with latest results.

[alexsherstinsky]

@dennisrall Do you think it might be simpler to retain the coding pattern of returning list(my_object.keys()) or list(my_object.items()), etc., instead of introducing a special additional methods item_list() and value_list()? It seems to me that doing so will be consistent with other cases in these Ludwig modules as well as general Python collection patterns. Thank you.

[alexsherstinsky]

@dennisrall Thank you for incorporating my previous suggestion -- I think that part looks clean now. Thank you for the idea and the implementation!

For this one, I am not sure if the benefits due to adding the MutableMapping subclassing justify taking the risk brought about the multiple inheritance. Do the test cover all the eventualities that might happen with this change?

Thank you. /cc @justinxzhao @arnavgarg1 @Infernaught

[dennisrall]

No problem, I was just playing around a bit.

I can't think of any problems about the multiple inheritance, but you know the code better than me😉

It is also possible to remove the MutableMapping inheritance and implement the other methods by hand. But I think this way it is a bit cleaner, if it doesn't cause any problems...

[alexsherstinsky]

@dennisrall This fixture and the to_module() one appear the same, and just instantiate the PyTorch Module() class. Without a docstring, it is a bit difficult to justify it having them. Thank you.

[dennisrall]

Thanks for your feedback. I added a docstring for both fixtures and also for the hash method of the LudwigFeatureDict

[justinxzhao]

Overall PR LGTM, thanks for the change @dennisrall.

I pushed up a couple of commits, largely around fixing the CI.

It appears we'll need to bump up integration tests CI to torch==2.1.0, which we're absolutely ok also since that's what our Docker images are using now.