Post postmodeling: A new hope #673
Conversation
old object interface.
| return evaluations.drop('_sa_instance_state', axis=1).set_index(['model_group_id', 'model_id', 'metric', 'parameter']) | ||
|
|
||
|
|
||
| class ModelGroup(Base): |
There was a problem hiding this comment.
Could the original definitions in https://github.com/dssg/triage/blob/master/src/triage/component/results_schema/schema.py be used? It would be nice to minimize the code that needs to be changed when the schema changes
There was a problem hiding this comment.
I will use them :)
| ).run() | ||
|
|
||
|
|
||
| session = create_session(shared_db_engine) |
There was a problem hiding this comment.
does this line do anything? (i notice that you're not using session, at least.)
| evaluations = evaluations.sort_values('evaluation_start_time', ascending=True) | ||
| evaluations = evaluations[['evaluation_start_time', 'value']] | ||
| evaluations['type'] = model_group.type.split('.')[-1] | ||
| return evaluations |
There was a problem hiding this comment.
this function needn't be declared dynamically, need it? I would think it can be declared at the module level, (rather than re-declared every time the wrapping function is called).
perhaps it'll need metric added to its signature, but that's all...?
There was a problem hiding this comment.
What do you mean? I am afraid that I am not following
There was a problem hiding this comment.
The function plot_metric_over_time will re-declare the inner function get_model_group_evaluations every time that the former is invoked. This is sometimes useful, but problems with it include:
- performance: the interpreter must recreate the function dynamically
- debugging & legibility: the inner function inherits a dynamic scope from every invocation of
plot_metric_over_time - testing & reusability: (if necessary), the inner function couldn't be either tested or reused with this factoring
Though the inner function here isn't huge, I would say it's big enough that it may as well be moved to the module scope, to avoid the above pitfalls.
There was a problem hiding this comment.
Makes sense! I will do it.
My idea was not to pollute the module namespace with this function that is only used inside this one, but, what are you saying makes a lot of sense. What will be a good case for using inner functions?
There was a problem hiding this comment.
Right! I think the same way. (But I've also been yelled at for doing so 😹)
The inner function – once moved to the module level – can at least be given a leading underscore to indicate that it's not intended as part of the module API.
I'd say the important thing is that inner functions be trivial – very short, (including lambdas of course).
But ultimately it's up to your judgement of the pros & cons relative to the situation.
Co-Authored-By: nanounanue <[email protected]>
Co-Authored-By: nanounanue <[email protected]>
|
@jesteria Thank you for all your comments! I will work on them |
This PR is about putting out there the new proposed API. It is still work in progress.
Missing parts:
I want to push this, so other people could start coding using this interface.