Review qiskit.Result API

[delapuente]

What is the expected enhancement?

After merging #773, review the qiskit.Result API to ensure it offers all the necessary now there is a new, more-powerful result format.

[diego-plan9]

Reviving this issue after closing #1023 and marking it as discussion, invoking @jaygambetta and others!

From the mentioned issue and conversations, it would be great if we could "stabilize" the Result "API" along with the upcoming releases - deciding which methods are to be deprecated, which ones stay, which ones need to be added, and a timeline for the changes:

• get_* family of methods: would it make sense to drop the get_, and instead name them counts, etc?
• removing methods: do we want to keep the methods that are not strictly related to retrieving information from a subfield (for example, average_data)? if so, part of the decision involves providing that functionality somewhere else, if relevant.
• new methods to be added: result.get_memory() command #1063 , others?

An alternative hinted by @delapuente is to make use of View or Browser objects that provide "richer" views of a base object.

[ajavadia]

i agree with changing get_* to just *.

[diego-plan9]

After internal conversation with Jay, here is a summary of the changes:

0.6 result	action	PR
__add__	deprecate	#1360
__iadd__	deprecate	#1360
__len__	remove (1)	#1360
__getitem__	remove (1)	#1360
average_data	remove (2)	#1351
circuit_statuses	deprecate	#1360
get_circuit_status	deprecate	#1360
get_counts	change return dict	#1404
get_data	rename	#1362
get_job_id	deprecate	#1360
get_names	deprecate	#1360
get_qubitpol_vs_xval	remove	#1360
get_ran_qasm	deprecate	#1360
get_snapshot	remove	#1378
get_snapshots	remove	#1378
get_statevector	keep but round	#1381
get_status
get_unitary	keep but round	#1381

(1) this was decided seeing that it was not used by the tests, and that it had not so clear semantics (as in, users can access result.results directly). They can be reintroduced if needed.
(2) already tacked in #1351, reintroduced as qiskit.quantum_info.analyzation

There are also some still to be decided issues:

• whether to deprecate as usual (keeping the old method with a warning during 0.7, removing in 0.8) or removing entirely. For the moment, a conservative approach has been taken, just deprecating (except for the two Python methods mentioned above)
• get_memory should be added as well (see [WIP] Support per-shot measurements + unified result postprocessing #1279)

[diego-plan9]

After #1360, updated the table below - the consensus is that the get_xxx methods will imply that some preprocessing might be applied to their return values (most notably, get_counts will have its keys in the right format, not hex), and get_data will be renamed to data, signalling that it will contain the raw information.