Split travertino.properties

[HalfWhitt]

Well, you were right. I found some time to start working on migrating the property aliasing down into Travertino, and while it's neither done nor presentable yet, I have enough to know that, with these additions plus composite_property, properties.py will probably end up longer than declaration.py was to begin with!

So here's a preemptive splitting. __init__.py maintains all the same symbols, so no imports break. Some bikeshedding could definitely be done on placement and naming, particularly:

• ImmutableList and Choices don't have a lot in common with each other, but they are both short classes used by properties; I could see grouping them into types or utils or something.
• We don't necessarily need to export ImmutableList; it's not actually used anywhere yet except in Travertino's tests. And even once it is used, it probably won't be imported anywhere within Toga. But it is a type we'll be returning to users...
• I've put validated_property and list_property together, as the latter is only a minor override. I've put directional_property in a file named shorthand. In the draft for composite_property, I factored out a base class for directional and composite and named it property_alias. Especially in light of the alias and deprecations we're now supporting, I think shorthand_property would be a better name for it, and the three can live together.

My in-progress work so far involves two classes:

• paired_property handles the alignment/align-items situation, where either one can be the source of truth and there's a translation process between them. This inherits from validated_property.
• aliased_property is a standalone class that handles the "straight-through" aliases and deprecations, with the option to specify conditions in which it's valid.

Since they conceptually share a goal, I'm thinking they could go together in a file, though I'm not sure what best to name it.

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]

Two comments:

• Agreed it makes sense for shorthand to exist as a placeholder; are you anticipating that composite will be a part of shorthand? If not, then I'd suggest it might be worth pulling out directional into it's own class as well
• Is there any need for the module-level __init__ aliases? Those would only be needed if the properties split was in the wild; but its not. In light of that, I'd rather expose a public interface of "import from where it's defined".

[HalfWhitt]

Agreed it makes sense for shorthand to exist as a placeholder; are you anticipating that composite will be a part of shorthand? If not, then I'd suggest it might be worth pulling out directional into it's own class as well

I am, yes — my idea was that shorthand.py would include shorthand_property, directional_property, and composite_property. Based on what I have so far, all three together should only be ~150 lines.

It's not a strong preference, though.

Is there any need for the module-level __init__ aliases? Those would only be needed if the properties split was in the wild; but its not. In light of that, I'd rather expose a public interface of "import from where it's defined".

Huh, I got my wires crossed and was thinking this was partly for backwards compatibility... but you're right, Toga <= 0.4.8 will never need to access any of these (except for Choices, which it will be importing from declaration). I can remove the __init__ and update the appropriate imports.

[freakboy3742]

Agreed it makes sense for shorthand to exist as a placeholder; are you anticipating that composite will be a part of shorthand? If not, then I'd suggest it might be worth pulling out directional into it's own class as well

I am, yes — my idea was that shorthand.py would include shorthand_property, directional_property, and composite_property. Based on what I have so far, all three together should only be ~150 lines.

It's not a strong preference, though.

Same. I wasn't sure how big composite_property was likely to get - but it it's ~150 lines, I'll leave it dealers choice how you split it up.

Huh, I got my wires crossed and was thinking this was partly for backwards compatibility... but you're right, Toga <= 0.4.8 will never need to access any of these (except for Choices, which it will be importing from declaration). I can remove the __init__ and update the appropriate imports.

👍

[HalfWhitt]

I wasn't sure how big composite_property was likely to get - but it it's ~150 lines, I'll leave it dealers choice how you split it up.

Hopefully I haven't jinxed myself!

[HalfWhitt]

...I'm now really confused how my local tests can pass despite the imports I missed.

[freakboy3742]

...I'm now really confused how my local tests can pass despite the imports I missed.

Stale __pycache__ files are a hell of a drug :-)

[freakboy3742]

👍 LGTM!