-
Notifications
You must be signed in to change notification settings - Fork 97
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
solution.Solution -- cannot pass frame=
as kwarg
#635
Comments
Yeah, the fact that the initialization does nothing if there are zero or 3+ arguments is very bad. Looking through the code, |
Edit: and |
It's no big deal to have different names for |
Looking at the current code I am not sure I see a way out of this dilemma without breaking something. Some thoughts though:
|
I think we can do something reasonable in a backward-compatible way:
If we are willing to make incompatible changes in the future, this could be revamped along the lines that Kyle suggests. |
Agreed. Better to not break things. |
I've implemented what I suggested in #636 . Could you both take a look? |
That fixes the problem I was having at least. I haven't tested it more extensively. I'm not sure what the recommended approach is more generally for cases like this where you want to be able to initialize in various different ways with the same |
I think keyword arguments are probably the right thing to use for this type of functionality and has the benefit of being less confusing. The one problem is if someone uses incompatible keywords but then you could check for that. |
I was having problems reading in a single frame of a solution using
solution.Solution
and finally tracked it down to the fact that although the first parameter ofSolution
is namedframe
you cannot call it using this as a kwarg, e.g. the two commands below should load the same frame but the second silently does nothing:The reason is that the code decides whether to read the solution based on this logic:
Surely there's a better way to get the desired behavior but also allow specifying the key word?
And if this gets rewritten, would it be better to call this argument
frameno
for consistency with what we do in visclaw and other places, or isframe
too heavily used elsewhere in pyclaw?The text was updated successfully, but these errors were encountered: