Since None is resolved inside EngineArgs or ModelConfig, I feel that we should not allow it to be None when initializing SchedulerConfig

The default is None so that the default in EngineArgs is None.

We have the same problem with the max_num_batched_tokens and max_model_length. It can't be optional in the config because maths is done on them in __post_init__, but they must have None defaults so that EngineArgs can have them as optional.

Where would you change behaviour so that the defaults here are not None?

Maybe we can have a from_optional method just like the one for SamplingParams to resolve the None values

Using post init to overwrite None values leads to a bunch of issues with type checking since downstream access of these attributes will unnecessarily need to consider the None case in order to avoid type checking errors.

Maybe we can have a from_optional method just like the one for SamplingParams to resolve the None values

Would we then need to change everywhere SchedulingConfig is instantiated? And then remember to instantiate it that way?

Using post init to overwrite None values leads to a bunch of issues with type checking since downstream access of these attributes will unnecessarily need to consider the None case in order to avoid type checking errors.

I agree, but that's why there in SchedulingConfig the type is int but in EngineArgs the type is Optional[int], so that the type cheking is happy.

I think it's worth noting that prior to this PR, this is how we handled max _num_batched_tokens.

I changed the other two here so that they would no longer have arbitrary defaults that could be inherited by EngineArgs

As per offline discussion, this is the cleanest way given how the configs are set up right now. We can address this later