> That's why I was more leaning towards a form of catch-all key. I think the main issue with this, as the code stands today, is that many of the functions that perform the validation compare provided keys to those keys in the spec to decide whether or not further work is needed (setting defaults, handling aliases, etc.). All that logic would have to be reworked in order to allow arbitrary keys (again, this is possible but the level of effort required does not seem to justify the change).
> While not terrible, in my view this misrepresents the data. I agree. It's the only disadvantage to this approach, especially when you need a dictionary and all the behaviors inherent to that type. Most of the time in Ansible, a list of dicts is sufficient to accomplish the same goal. But I do understand the drawbacks. --- Respectfully, Sam Doran Ansible Core -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/4B33D2DD-ACDF-478D-97EC-70AB1A5E5CAF%40redhat.com.
