In preparation of larger refactor works in flopy, we discussed with @wpbonelli and @mjreno that it would be beneficial for readability to change the PackageContainer to a composition pattern, rather than inheritance. Only 7 functions need to be duplicated in MFSimulationBase, MFPackage, and MFModel as pass-through functions. There should be no compatibility issues for the users, as the signature hasn't changed.

My doubts

There are some public API functions that are now part of MFPackage, MFModel, MFSimulationBase of which I doubt if we should keep them. They don't seem to be called in any tests and I wonder if they should be available. The function that seems reasonable to keep is therefore only get_package, and maybe only for MFSimulationBase.

• package_key_dict
• package_dict
• package_names
• package_type_dict
• package_name_dict
• package_filename_dict

I changed MFPackage._simulation_data to MFPackage.simulation_data to be consistent with MFSimulationBase and MFModel. Also because it is used by output_util.MF6Output (line 115).

Breaking changes

Static variables modflow_packages, packages_by_abbr, modflow_models, and models_by_type should be called via PackageContainer.modflow_packages etc. If these variables are part of the public API, the users might need to change some code to no longer call MFPackage.modflow_packages or the like.

It is possible to make this a non-breaking change by introducing a meta-class, but if possible the user does not need these attributes, I would try to not take this route.

class PackageContainerProperties(type):
    @property
    def modflow_packages(cls):
        return PackageContainer.modflow_packages

class MFPackage(metaclass=PackageContainerProperties):
    ...