Problem description

After the introduction of new YAML features (especially in Python), there has been some discussion of minor 'paper cuts'. Below is a list of issues that could/should be addressed:

• Unpythonic method names Reaction.fromYaml, Reaction.listFromFile, Reaction.listFromYaml ... fix proposed in Reaction rate factories #1061 (now merged)
• Similar for Species.fromYaml, etc. … fix proposed in Read YAML using C++ newSolution in Python / access root level data #1129 (now merged)
• Per comment in Enable modification of user input data fields in Python #1031, it would be nice to have Solution.write_yaml be able to write into a string … added to Pickle serialization of Solution objects #692 (now merged)
• It would be nice to have constructors that use keyword names that correspond to YAML field names. This is somewhat complicated by the occurrence of hyphens in many top-level fields (e.g. rate-constant for reaction definitions, see Refactor reaction rate evaluators #995); an alternative @classmethod from_dict is an approach that does not have this limitation.
• With the introduction of dict_to_anymap in Implement Python dict to C++ AnyMap conversion #1014, it is now possible to pass dictionaries that are equivalent to YAML definitions to the Python API. In Refactor reaction rate evaluators #995, a new Reaction.from_dict is proposed (now merged). The same is possible for various other imports. ... fix proposed in Resolve Yaml paper cuts #1179
• With Enable serialization of Cantera objects #984, the input_data field was introduced, which corresponds to the dictionary that can be used by from_dict. A consistent naming scheme may be beneficial, especially as the field does not preserve the original parameterization (see Enable modification of user input data fields in Python #1031). ... probably not an issue
• It would be nice to allow for mixed dict/YAML string imports for dict_to_anymap (see Refactor reaction rate evaluators #995). ... implementation proposed in Resolve Yaml paper cuts #1179, but dropped
• At this point, YAML may refer to a file, string, or even a corresponding Python dictionary, where the context isn't always clear. ... probably not an issue
• Root level information of the YAML parameterization is not accessible, see also Serialization of root-level information in YAML #1013 … fix proposed in Read YAML using C++ newSolution in Python / access root level data #1129 (now merged)
• Per comments in Enable modification of user input data fields in Python #1031 and Enable serialization of Cantera objects #984, there is some inconsistency of C++ definitions for input, which either refers to a member variable or a class method. As this was initially introduced in WIP: YAML input file format #584 (and/or related PR's), this part of the API is already released in 2.5.1 and thus is difficult to address. ... not sure that this should be addressed
• There are some imperfections for YAML emitted output, see Improve YAML output formatting #1128 … fixed in Improve YAML formatting #1133

Additional context

Some of the unpythonic method names are based on historic equivalents for XML and CTI. As those are to be deprecated, a renaming of legacy methods appears to be unwarranted.