Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OptionList breaks backwardscompatibility from 0.4.1 to 0.4.0 #2302

Closed
Kuna42 opened this issue Dec 28, 2023 · 1 comment · Fixed by #2335
Closed

OptionList breaks backwardscompatibility from 0.4.1 to 0.4.0 #2302

Kuna42 opened this issue Dec 28, 2023 · 1 comment · Fixed by #2335
Labels
bug A crash or error in behavior. documentation An improvement required in the project's documentation.

Comments

@Kuna42
Copy link

Kuna42 commented Dec 28, 2023

Describe the bug

Keywords are incompatible from 0.4.0 to 0.4.1

Steps to reproduce

  1. Write code with keywords in toga 0.4.0
  2. Update to toga 0.4.1

Expected behavior

The keyword should be recognized.

Screenshots

No response

Environment

  • Operating System:
  • Python version:
  • Software versions:
    • Briefcase:
    • Toga: 0.4.0 -> 0.4.1

Logs

TypeError: OptionList.append() got an unexpected keyword argument 'text'

Additional context

The Documentation of 0.4.1 shows, what breaks the backwards compatibility.
The keyword is now text_or_item instead of text
grafik

I would favour the keyword item if an OptionItem and text if it is a string.

@Kuna42 Kuna42 added the bug A crash or error in behavior. label Dec 28, 2023
@freakboy3742
Copy link
Member

Yes, the first argument to append() has changed; that should have been noted in the release notes.

We could potentially add a text keyword argument for backwards compatibility; however, given that 0.4.1 has been released with this change in place, it would be an affordance that would get minimal use, as anyone depending on the argument name would have made the update as part of upgrading to 0.4.1.

We're not going to add separate text and item arguments; the argument is positional, not intended to be passed in as a keyword. Breaking the argument into two parts has no benefits, and significantly increases the complexity of the method as we need to handle "provides both" and "provides neither" use cases, as well as type checking that text and item have been provided as the right types.

There's potentially a need for a policy decision here about backwards compatibility when it comes to positional and keyword arguments; as part of that change, we should be enforcing the use of keyword arguments in more of the API. I've opened #2308 to track this.

@freakboy3742 freakboy3742 added the documentation An improvement required in the project's documentation. label Dec 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A crash or error in behavior. documentation An improvement required in the project's documentation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants