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

AeroProblem should throw an error when an unsupported kwarg is passed into the initialization #94

Open
gawng opened this issue Apr 23, 2024 · 2 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@gawng
Copy link
Contributor

gawng commented Apr 23, 2024

Description

Andrew from AERO740 found that when xref, not xRef is passed into AeroProblem(), the initialization is just fine even though nothing is happening.
I think baseclasses should return an error.

  1. This could be modifying the AeroProblem python code to check a list of all supported keyword arguments. Return an error if the supplied arg does not exist in the supported keyword arguments.
  2. Another method could be changing the function signature of the __init__() to list out all the kwargs.

I am open to hearing other approaches too.

Steps to reproduce issue

Something like
ap = AeroProblem(args=args, unsupportedArg=randomValue)
or rather
ap = AeroProblem(xref=0.5) does not return an error that you're not setting xRef as intended

Current behavior


Does not throw an error for unsupported keyword arguments in AeroProblem instantiation.

Expected behavior


Throw an error for unsupported keyword argument

Code versions

  • Operating System:
  • Python:
  • OpenMPI:
  • CGNS:
  • PETSc:
  • Compiler:
  • This repository:
@A-CGray
Copy link
Member

A-CGray commented Apr 26, 2024

Yes I agree, we did a similar thing in https://github.com/mdolab/pylayout/pull/24, I think either approach is fine

@gawng gawng added good first issue Good for newcomers bug Something isn't working labels Apr 26, 2024
@lamkina
Copy link
Contributor

lamkina commented Oct 9, 2024

Following up on this, my preference is listing all the args and kwargs in the __init__() definition because Python will handle the error automatically. If we add any other form of checking the code addition will be similar. We should do this for all of the Problem classes as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants