Make Accessors Optional for `ListSource` and `TableSource`

[corranwebster]

What is the problem or limitation you are having?

Currently the accessors argument is required when creating a ListSource or TreeSource but it is only used when converting sequential data (like lists and tuples) to Row or Node objects. For data sources where rows are completely constructed from mappings it is redundant. The accessors are also a private data item so there is no public way for a user of the data source to ask how sequential data should be supplied.

Describe the solution you'd like

Make the accessors argument optional, and rather than raising an error when constructing the data source, instead only error if it is absent and the user actually supplies a sequential data value for a row if the accessors are not supplied then treat sequences as opaque objects and pass them as {'value': data} to the Row's __init__ method (perhaps after converting them to tuple so they are immutable).

Also make it a public read-only attribute (perhaps as accessor_order or something similar).

Describe alternatives you've considered

Keeping the status-quo. It works. This is just streamlining the API.

Additional context

This came out of this comment: https://github.com/beeware/toga/pull/4042/changes#r2680642184

[freakboy3742]

+1 to the idea of softening the requirement.

My initial API suggestion would have been the "raise error" version that you've struck out. Constructing a row over a tuple is an interesting idea; but considering the overlap with #4042 - won't that also require Column (and all the text()/icon() etc APIs) to gain an awareness of the index of the column being resolved?

[corranwebster]

Constructing a row over a tuple is an interesting idea; but considering the overlap with #4042 - won't that also require Column (and all the text()/icon() etc APIs) to gain an awareness of the index of the column being resolved?

No, I think the idea is slightly different that what you're suggesting here. The behaviour would be very similar to what happens now if you pass a string or other non-mapping in as a row, but with a default "value" accessor.

This makes the non-accessor case for adding rows simple:

• if you pass a mapping you get a Row with attributes matching the keys
• if you pass any other object else (class instance, Sequence, whatever), you get a Row with one attribute value and the object as the payload - essentially like the ValueSource behaviour.

So if you have a column with accessor "value" then what you would see is either the str() of the object as the text (so a list might appear as ["foo", "bar", 2] for example (which isn't great, but at least is consistent and no worse than what you get from any other object without a nice __str__ method), or in the special case of a 2-tuple it would be interpreted as an (icon, text) tuple as usual. All other columns would give a missing value result.

But I can see what you're getting at regarding #4042 - if the Column API is made public, then someone could write a column type that expects values which are lists and select a particular element from it. But that shouldn't be the default behaviour.

The other simple option for non-accessor adding rows would be:

• if you pass a mapping you get a Row with attributes matching the keys
• otherwise raise an error because we don't know what accessor to assign it to

[freakboy3742]

So if you have a column with accessor "value" then what you would see is either the str() of the object as the text (so a list might appear as ["foo", "bar", 2] for example (which isn't great, but at least is consistent and no worse than what you get from any other object without a nice __str__ method), or in the special case of a 2-tuple it would be interpreted as an (icon, text) tuple as usual. All other columns would give a missing value result.

I feel like I'm missing something... won't that be massively backwards incompatible?

The existing Table example uses "list of tuples", so this suggestion would result in moving from generating Row(name="Bees", year=1998, ...) to Row(value=("Bees", 1998, ...)). Sure, that's an option... but how does the Table adapt in a way that doesn't break the existing example's behavior?