__getattr__ but no __setattr__ implemented on ports causing confusion...

[carldlaird]

_PortData implements getattr to support accessing .vars['foo'] using the attribute ".foo". This caused me confusion since m.port.foo returned a simple var, but m.port.foo = 42 failed.

Should we have design discussion here about the symmetry and either implement setattr or not implement getattr (or somehow return a more helpful error when we try m.port.foo = 42)?

@gseastream (Thoughts?)

[gseastream]

So to describe what's going on in case some may not be familiar, doing something like m.bar.foo = 42 to set the var's value to 42 works when bar's class implements setattr to check if the key foo is in the dict, and if it's a component, and then calls the set_value method on 42. Blocks do this, which is why people are familiar with doing m.foo = 42. But Port does not do this. Actually on a related note when I was digging around in IDAES code I saw someone wrote buggy code that tried to do m.connector.vars["foo"] = 42 to try to set the var's value that way too, but that doesn't work since vars is just a dict that doesn't do that setattr magic (so it just reassigned the dict entry to be the constant 42).

How many users want to be able to do m.port.foo = 42? If that is what people want, then I could imagine implementing the setattr magic for ports... But we don't have any other components that do that besides blocks to my knowledge. But doing it would be easy.

It would also be easy to include a helpful warning in setattr if we didn't want to include the set_value magic, so if the user tries to do this on a component that is in the vars dict then we error.