-
Notifications
You must be signed in to change notification settings - Fork 90
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
Depracation warning for parameter names not being valid python identifiers #337
Conversation
…dentifier First step for solving #274. This covers all outcome and parameter classes. Still remaining are constants and potentially all Point subclasses.
from NamedObject to Variable, which means Constant name now also must be a valid python identifier
for more information, see https://pre-commit.ci
…kbench into valid_identifiers
for more information, see https://pre-commit.ci
Globally, looks good! Ideally, clean up the commits into:
Otherwise squashing on merge would also be fine. I would just make sure it doesn't cause major conflicts with #274. |
Co-authored-by: Ewout ter Hoeven <[email protected]>
How would I manage reorganizing the commits because I agree that a clean history would be a convenient. |
In my process I use GitHub desktop. You can drag and drop commits to reorder them. Then you squash the ones that work on the same feature (for example squashing all the testing commits to one commit). See Reordering commits in GitHub Desktop. If you're more of a CLI person: 7.6 Git Tools - Rewriting History. |
See #274 for details. This just turns the exception into a deprecation warning in preparation for the 2.5 release