This removes what I would expect to be the most common use case: specify only a device config name, but not the version (run or snapshot).

@eliottrosenberg - do we really want to support a default config name ("config alias") at all? While defaults make sense to get the "latest" version, a default grid seem more risky and I think are worth forcing explicit selection.

The methods inEngine are intended to be easy-to-remember convenience helpers and I'm concerned that over-specialization makes these less usable and more painful to maintain. e.g., if we add another feature with 2 ways to construct a sampler and follow this pattern, these 3 functions will turn into 6 new functions with very long names.

Thestyle guide suggests that defaults are useful to avoid "lots of functions for the rare exceptions", and@eliottrosenberg made it sound like these specialized versions are exceptional.

Would it suffice to just check for mutual exclusivity of the arguments and raise an exception if that's violated? Alternatively, if you find it important to bake this check into the interface, you could alternatively do it with the type system, e.g.:

@dataclassclass Snapshot:  id: str@dataclassclass Run:  id: strtype DeviceVersion = Snapshot | Runclass Engine  ...  def get_sampler(     self,     processor_id: str | list[str],     device_config_name: str,     device_version: DeviceVersion | None = None,     max_concurrent_jobs: int = 100,  ) -> cirq_google.ProcessorSampler:  ...

WDYT?

@hoisinberg and I were discussing this exact pattern. Yes this is better I think.

Could this be simplified by adding asampler() method onProcessorConfig? The equivalent of.get_sampler_from_run_name(...) would then be.get_config_from_run_name(...).sampler(). As a bonus, this form localizes scope of each resource configuration, e.g. expanded:

sampler = (    engine.get_processor('willow_123')        .get_config_from_run(run_name='current', config_name='some_cool_grid')        .sampler())

This or something like it should probably the the canonical form of retrieval because a sampler should always refer to a fully-qualified config even if the user used defaults to construct it.

I like Will's suggestion.

Following on from the above comment regarding the requirement of a device config to build a sampler, should we removeget_sampler from the processor and instead rely on explicitly grabbing the default configuration to generate the sampler?

I agree with Will about removing theget_sampler methods of the processor, althoughengine.get_sampler() is useful as a convenience function so that you don't always have to get a config first.