Dict[str, Any] or Dict[str, Field] in pytext
I'm reading the document of pytext (NLP modeling framework built on PyTorch) and this simple method from_config, a factory method to create a component from a config, has lines like Dict[str, Field] = {ExtraField.TOKEN_RANGE: RawField()}.

@classmethod
def from_config(cls, config: Config, model_input_config, target_config, **kwargs):
    model_input_fields: Dict[str, Field] = create_fields(
      model_input_config,
        {
            ModelInput.WORD_FEAT: TextFeatureField,
            ModelInput.DICT_FEAT: DictFeatureField,
            ModelInput.CHAR_FEAT: CharFeatureField,
        },
    )
    target_fields: Dict[str, Field] = {WordLabelConfig._name: WordLabelField.from_config(target_config)}
    extra_fields: Dict[str, Field] = {ExtraField.TOKEN_RANGE: RawField()}
    kwargs.update(config.items())
    return cls(
        raw_columns=config.columns_to_read,
        targets=target_fields,
        features=model_input_fields,
        extra_fields=extra_fields,
        **kwargs,
    )


and 

    def preprocess(self, data: List[Dict[str, Any]]):
        tokens = []
        for row in data:
            tokens.extend(self.preprocess_row(row))
        return [{"text": tokens}]



How can a dictionary have keys with 2 items? What exactly is this?

I would appreciate any pointer! 

What you're seeing are python type annotations. You can read about the syntax, design and rationale here and about the actual implementation (possible types, how to construct custom ones, etc) here. Note that here List and Dict are upper cased - Dict[str, Any] is meant to construct the type "a dictionary with string keys and Any values" and not to access an instance of that type.

Those are optional and by default are not used for anything (so you can just ignore them when reading your code, because python also does). However, there are tools like mypy which can interpret these type annotations and check whether they are consistent.

I don't know for sure how they are used in torchtext - I don't use it myself and I haven't found anything quickly searching the documentation - but they are likely helpful to the developers who use some special tooling. But they can also be helpful to you! From your perspective, they are best treated as comments rather than code. Reading the signature of preprocess you know that data should be a list of dicts with str keys and any value type. If you have bugs in your code and find that data is a str itself, you know for sure that it is a bug (perhaps not the only one).
