Repo Added
|
Files
872
|
Badge
README BADGES
|
push
github
Document subclass considerations for `Target` (#15220) (#15231) * Document subclass considerations for `Target` The documentation of `Target` previously implied that subclassing it is ok, and we have users that have done that. However, subclassing it is fragile, does not affect any transpiler pass that reads from the `Target` in Rust space, and requires the subclass to arrange for `__new__` to be called correctly. I re-added a `**kwargs` variadic in `Target.__new__` as a minor convenience; subclasses that only add keyword-only arguments (which are generally the safest things to add) will remain functional. Had `Target.__new__` been defined in terms of keyword-only arguments, we could also have added an `*args` munch too, but as it is, adding or modifying the positional arguments to a `Target` subclass constructor _always_ requires overriding `__new__` as well to avoid clobbering positional `description`, `num_qubits`, etc, so there's no benefit to having `*args`. We should be discouraging users from subclassing `Target`; even our own subclass of the Python-space `Target` from the Rust-space `Target` is rather fragile with how we attempt to keep data in sync between the two. Most APIs exposing a `Target` to their users would probably be better as constructor functions; this is supposed to be the default way of building a `Target`. * Reexplain constructors vs subclassing --------- (cherry picked from commit b6484afde) Co-authored-by: Jake Lishman <jake.lishman@ibm.com> Co-authored-by: Shelly Garion <46566946+ShellyGarion@users.noreply.github.com>
1 of 1 new or added line in 1 file covered. (100.0%)
10 existing lines in 3 files now uncovered.92391 of 104491 relevant lines covered (88.42%)
539354.87 hits per line
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|