-
Notifications
You must be signed in to change notification settings - Fork 12
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
better error message for breed #74
Comments
One way to solve this is to provide the chromosomes as a list/tuple to a single argument of the combiner. Then it is the user's responsibility to extract the chromosomes from the list. |
its a breaking api change though. it might help make many things much clearer though. |
A downside of passing the parents in a sequence instead of multiple arguments is that lambda combiner functions lose elegance; e.g. when using a chromosome class with a
to
|
Found bug #76 while playing with this problem |
One can try to solve this problem by making the non-chromosome arguments keyword only arguments. E.g., a function defined as
can not be called as Forcing our users to do this would require that we can detect whether or not an argument is supposed to be a chromosome. Since we do not know the type of a chromosome (it could be anything from a float to an object) we cannot rely on annotation (type hints) of the arguments, let alone that we cannot rely on users properly annotating the arguments to their functions. Also, we cannot rely on the extra arguments to have a default value - as they may not have that by design - or the chromosome arguments to have no default value (e.g. a function like Hence passing the chromosomes in a single argument is still the only solution that will catch every exception. So do we want this to be completely fool proof, or can we live with making our own combiners have keyword-only arguments and possible augmenting the message of exceptions that are raised in the |
I think making it fool proof is better. A single rule is better than many and after having thought about it, i like the idea that chromosomes will always be an iterable ... preferably a tuple maybe ... but definitely just a single variable. It makes everything less suprising and much easier to provide useful errors. The main downside is that this change will break a lot of things and is a breaking API change. Technically, this means that changing this might make evol v1.0.0. |
See #78 |
Suppose that we are working with this bit of code.
Can you find the error? It gives an error.
The user forgot to specify the number of parents in the parent picker. This is something that could go wrong rather often and it is something that needs a better error message. Something in order of "your parent picker outputs 2 parents but your parent merger only assumes one".
The text was updated successfully, but these errors were encountered: