Tests and fixes to new data api #407
base: new_data_api
Are you sure you want to change the base?
Conversation
@staticmethod | ||
def from_params(params: Params): | ||
choice = params.pop_choice('type', list(token_indexers.keys()), default_to_first_choice=True) | ||
return token_indexers[choice].from_params(params) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are you putting this code? This was intentional, actually, and makes constructing objects from params a lot easier. If it's not here, it has to be duplicated every time you want to construct an object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't have this here because it creates circular imports - token_indexers
are imported from __init__
but haven't been defined yet. We also can't import the classes directly because they inherit from this class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One idea to fix this would be to have parameter checking only at the Model level. This would remove the need for the from_params
on everything and we could just log parameters inside classes. This would have the benefit that the log would show where the parameter was defined, which it currently doesn't because all the logging happens in params. The replicability is nice, but we now achieve that with Dockerised experiments, so maybe it is less useful. I don't know about you but I have never really used the logged parameters past a "those look right" sort of check anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just move the import inside the method to remove the circular import. We really do want everything to be constructed from_params
, so that we can have a single configuration file that runs a whole experiment (i.e., it's not just parameter checking that this gets us). Having this here makes it so that things like this work. Otherwise it's more complicated to do the construction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, will do
from ..vocabulary import Vocabulary | ||
from .token_indexer import TokenIndexer, TokenType | ||
from deep_qa.common.util import pad_sequence_to_length | ||
from deep_qa.common import Params |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be relative, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks
…ome tests which use the model
In summary this PR does the following few things:
|
This looks great to me, from my somewhat quick look 👍 . I didn't see any big API changes in this, just testing and cleanup, right? It's nice to have usage examples in the test suite, thank you for adding them! |
No description provided.