What was the impetus for this upgrade? Is it just for the enum? Not that I disagree, just want to understand. Also, why not upgrade to latest version? (I am assuming latest involves more refactoring?)

I wanted to get Duration conversion but that's only in latest, I kept what I could. There is no pyo3-asyncio that supports latest

Why update at all if you couldn't update enough to get the feature you wanted? (not that I disagree w/ an update for update's sake, just checking if there was something else in 0.20 you're leveraging)

Just to understand, can you confirm with these context changes what the error string looks like to Python users now? I just want to see exactly what the concatenation looks like since it's not explicit anymore.

Yeah, I'll double check what it looks like, but I doubt it's materially different

Is this a temporary limitation?

No. It always needs to be this way, otherwise whatever slot type has lower targets could be completely starved out by the one with higher targets. Since you're targeting system resource use, it doesn't really make sense to have different targets within the process.

This makes sense, I just wanted to confirm before some of my other suggestions in this PR

We do this in plenty of other places, it's fine for the bridge (we usually use _millis suffix)

Sure, it'd be nicer if it just worked though

While we try to use kwargs as much as possible, I can understand the use case here, but I think we should suffix it with Config (we've done this in a few other places)

I am not sure this should exist now that I think about it. I think this can be on worker tuner:

class WorkerTuner(ABC):
    @staticmethod
    def create_resource_based(
        *,
        target_memory_usage: float,
        target_cpu_usage: float,
        workflow_slot_config: Optional[ResourceBasedSlotConfig] = None,
        activity_slot_config: Optional[ResourceBasedSlotConfig] = None,
        local_activity_slot_config: Optional[ResourceBasedSlotConfig] = None,
    ) -> WorkerTuner:
        # Create composite tuner

I have no strong opinion on those trailing 3 kwarg names (e.g. can be workflow_config:)

K, I can go with that

This technically doesn't need to be required, though I am ok that it is.

I am now thinking that this class doesn't need to be exposed either but instead can also be a static method on worker tuner that accepts these three kwargs and returns a worker tuner. There is no value from a user POV to expose a new type vs just a method to make a worker tuner from these three values.

(note, I will disagree with myself here when it comes to .NET)

I wonder if there is a way for us to introspect the tuner at this time to find its max activities

Another approach is to just have WorkerTuner have a private _create_bridge_tuner method, so something like:

if tuner:
    if max_concurrent_workflow_tasks or max_concurrent_activities or max_concurrent_local_activities:
        raise ValueError(
            "Cannot specify max_concurrent_workflow_tasks, max_concurrent_activities, "
            "or max_concurrent_local_activities when also specifying tuner"
        )
else:
    tuner = WorkerTuner.create_fixed(
        max_concurrent_workflow_tasks=max_concurrent_workflow_tasks,
        max_concurrent_activities=max_concurrent_activities,
        max_concurrent_local_activities=max_concurrent_local_activities,
    )
bridge_tuner = tuner._create_bridge_tuner()

That at least moves the defaults and all tuning code to one place and only requires importing the WorkerTuner

Let's change this to Config too