You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current 3 layers to provide config options (like solver or endpoint):
config file (all options)
environment variables (limited set of options)
keyword arguments to Client's constructor and from_config (all options)
it is impossible to "suggest" default option values (e.g. solver), but allow for user to override it on any of the 3 layers. Possible use cases:
user wants to set a soft default in code (layer 3), but allow override from environment
3rd party library has a notion of preferred defaults, but wants to allow an easy override for its users
Proposal: implement a mechanism to provide config options on layer zero -- a per-Client instance default value for each config option, provided on construction.
For example, adding defaults argument to Client constructor and from_config, which would .update the Client class-level defaults for all accepted config options. Additional benefits of this are: consolidation of the defaults, clearly documenting all accepted config options in one place. It can be nicely combined with #357.
The text was updated successfully, but these errors were encountered:
Core functionality of dwavesystems#425.
Note: compatibility break -- Client init now takes ONLY THREE positional
arguments (endpoint, token, solver). In the future, we want to deprecate
pos args completely.
This compat break should have **minimal** impact. Legacy code used to
provide only endpoint and token via pos args.
Changes since 0.7.7:
New Features
---
- `Client` instance defaults via `defaults` constructor argument (#425)
- `Client` class defaults in `Client.DEFAULTS`
- Parsing of boolean options in configuration files. `on`/`off`,
`true`/`false`, `1`/`0` all work as expected (#113)
- `@deprecated` utility decorator
- `aliasdict` utility `dict` subclass enabling lazy access to alias keys
Fixes
---
- Documentation refactor and update
Changes
---
- Removed legacy config file format (`.dwrc`) support (#138)
- Removed some of the deprecated `Solver.is_*` properties
- Removed support for deprecated formats: `bqm-ref` and `bq-zlib`.
- Removed support for more than first three positional arguments in
`Client` constructor (`endpoint`, `token` and `solver`). Positional
arguments in the constructor will be deprecated eventually.
- `Client.solvers` scheduled for removal in 0.9.0
- Deprecated `Future.occurrences` in favor of `Future.num_occurrences`
- Deprecated `samples` and `occurrences` keys in
`Future`/`Future.result()`
With the current 3 layers to provide config options (like
solver
orendpoint
):from_config
(all options)it is impossible to "suggest" default option values (e.g. solver), but allow for user to override it on any of the 3 layers. Possible use cases:
Proposal: implement a mechanism to provide config options on layer zero -- a per-Client instance default value for each config option, provided on construction.
For example, adding
defaults
argument toClient
constructor andfrom_config
, which would.update
theClient
class-level defaults for all accepted config options. Additional benefits of this are: consolidation of the defaults, clearly documenting all accepted config options in one place. It can be nicely combined with #357.The text was updated successfully, but these errors were encountered: