SelectField choice refactoring

[azmeuk]

Fixes #692. Related to #381.

SelectField choice argument can take a list of 3 items tuples, the last one being a dict that will be rendered as <option> HTML parameter.

[kontur]

This would be very useful 👍

[azmeuk]

@davidism does this sound safe to you?

[davidism]

Seems good to me. Instead of passing longer tuples, you might want to consider a SelectChoice dataclass with the fields, which might make typing easier later.

[azmeuk]

Do you mean we should break the compatibility and expect the choices parameter to be a collection of SelectChoice instead of a collection of tuples?
I suppose this would make the code more explicit and easier to read though.

[davidism]

Don't add a 3-tuple data type. Instead, only support this new data in the new dataclass. If you get a string, or a 2-tuple, convert it to the dataclass.

Since choices can be set after init, I'd do this conversion in the render step for now (and maybe in init as well). I'd probably keep the string shortcut, but show a deprecation warning for 2-tuples like "Passing (value, label) is deprecated, pass SelectChoice(...) instead.".

[azmeuk]

Sorry for the noise with the force pushes, that should be good now.

I refactored the SelectField by adding a Choice dataclass. I deprecated passing choices by tuples or dicts. The Choice dataclass carry the optgroup and render_kw.
This was a good idea @davidism I did not realized of much this would simplify the SelectField behavior 👍

I could use another review 🙏

[ThiefMaster]

Please reconsider this. It will be a significant amount of busy-work for larger projects to adapt to this, without any real benefit. Just generating the Choice instance from the tuple is cheap and doesn't seem to have any drawbacks.

Yeah... I really do not want to spend time updating those almost 50 places in my app.

[coleifer]

This breaks a few libraries, including wtf-peewee which passes two-tuples.