Where did "prepare_for_model" go?  What is the replacement?
I'm working with already numericalized data (e.g., where the text has been converted to ids via `tokenizer.tokenize()`) and was using `prepare_for_model` to build the appropriate input dictionary ... ***but*** that method is gone in 3.0.

So ... what should I use/do now?

Thanks
Hi! Why were you using `tokenize` + `prepare_for_model` instead of `encode`/`encode_plus` ? Let's see how to fit your use-case with the best approach!<|||||>Sure.

I'm the developer of [this library](https://ohmeow.github.io/blurr/) which integrates huggingface with fastai.  Probably the best thing is to look at the code [here](https://github.com/ohmeow/blurr/blob/master/blurr/data/core.py) to see what I'm doing.

The fastai bits don't work all that well with inputs composed of multiple tensors, and so my initial fastai transform converts the text to ids, which are then wrapped in a tensor to make fastai happy.  Before batches are created, I would use `prepare_for_model` to get the necessary transformer inputs (e.g. input_ids, attention_mask, etc...), pad to max length, etc..., using those ids.

@sgugger may have some thoughts on how to adapt my code better to v3 given he wrote most of those pieces in fastai :)

Thanks!<|||||>@LysandreJik Would it be possible that you link this issue in the "breaking changes" section for the 3.0.0 release 🤔 

In Flair we had the same issue :)<|||||>Hmm, I see, let me investigate. Does using the private `_prepare_for_model` solve your issue? I'll ping @n1t0 as well as he might have more info on that front.

@stefan-it, just did! Thank you.<|||||>Ok, indeed I'll add it as a breaking change also we could expose it publicly again in a 3.0.1 if it happens that many people were using it.

The main reason I made it private is that we don't have it in fast tokenizers (though we could maybe work on having it) and I'm trying to have both APIs come closer to each others.

@n1t0 do you think we could provide an implementation of this method in Fast tokenizers? It's basically all the post-processing (truncation + merging pairs + padding) after the conversion in integer indices.<|||||>We should be able to expose the post-processing for both `List[str]` and `List[int]` in `tokenizers`, but I'll have to check. I think the only problem in doing so is that all the mappings (chars <=> tokens <=> words) and offsets won't make any sense in this case.<|||||>Ok, we will release a patch to fix this breaking change (re-expose `prepare_for_models` for both slow and fast tokenizers with backward-compatible API) plus the one mentioned in #5377 probably tomorrow or early next week.