Evgeni Burovski a écrit :
It seems to me we are all saying pretty much the same thing:
More or less ;) I agree with most of your points, some more comments below.
2. Since __init__ is always called, various initialization strategies can be handled as a keyword arg in __init__(..., init_method="latinhypercube"), possibly overloaded for a callable or a population from a previous run? Or maybe the latter (reusing a population) is better handled by an alternative constructor. But this is certainly separate from both the context manager or iteration.
We can certainly do that. As mentioned in the PR thread, it seems to me that __init__ method is not the proper place to run (possibly long) calculations such as population initialization. This is just a matter of separation of concerns.
6. OptimizeStep could be a (current version of) OptimizeResult. In fact, I'd suggest it *is* an OptimizeResult.
Not sure I agree here. It seems to me that there's some value in distinguishing a step from a final result and using a different type looks appropriate. If you get an OptimizeResult at every iteration of the loop, it would be incomplete; missing in particular the "status" and "message" attributes, unless we set them to, e.g., status=None, message="in progress". This could bring confusion to the user who wouldn't know if its result is actually a result or just a step unless they introspect its content. To continue discussion on technical aspects, I would suggest moving back to the PR thread.