Fixed update/init with padding

[HalfWhitt]

One more cleanup from #3033. padding and its children worked fine when being set, but Pack(padding=1) or style.update(padding=1) still threw an error. Fixed and tested.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

Nice catch!

[HalfWhitt]

If only I'd caught it as part of the first PR!

One thing I've been noticing / thinking about... BaseStyle accepts hyphenated or underscored forms of its property names in __init__, update, and bracket notation; dot lookup is the only place it requires underscores. For consistency, would it be a good idea for Travertino's __getattribute__ to also do the conversion?

Edit: or is the idea that the other three are intended to be more flexible when receiving strings/dictionaries, while in normal usage dot lookup will only be used "literally"?

[mhsmith]

It's not syntactically possible to use hyphens with dot notation, because they would be parsed as a subtraction operator.

In fact, I'm not really sure why we allow bracket notation and hyphenated forms at all. @freakboy3742: what's the use case for this?

[HalfWhitt]

It's not syntactically possible to use hyphens with dot notation, because they would be parsed as a subtraction operator.

Oh right, duh 🤣 Brain fart moment there.

In fact, I'm not really sure why we allow bracket notation and hyphenated forms at all. @freakboy3742: what's the use case for this?

I've always assumed the former is for easier dynamic application and retrieval of properties without lots of settattr/getattr, and the latter is thinking ahead for CSS intake, I guess? Yeah, I'm curious too.

[HalfWhitt]

One other data point is that BaseStyle.__str__ returns a form with hyphens. Which looks more like CSS, I suppose, though it lacks semicolons.

[freakboy3742]

In fact, I'm not really sure why we allow bracket notation and hyphenated forms at all. @freakboy3742: what's the use case for this?

I've always assumed the former is for easier dynamic application and retrieval of properties without lots of settattr/getattr, and and the latter is thinking ahead for CSS intake, I guess? Yeah, I'm curious too.

Yes - the hyphen form was to accomodate the "preferred" form of CSS directives.

I don't know that I have a good reason for including the bracket form and having __setattr__/__setitem__ parity, other than "...well what else are you going to use __setitem__ for?", and maybe a weak argument that it allows you to use hyphen notation for styles in "natural" Python syntax (i.e., style["foo-bar"] reads as more natural Python, as opposed to setattr(style, "foo-bar", value)).