py uiout was: Re: [PATCH 3/3] PR gdb/13860: don't lose '-interpreter-exec console EXECUTION_COMMAND''s output in async mode.

[Matt Rice <ratmice at gmail dot com>]

On Thu, May 10, 2012 at 7:00 AM, Pedro Alves <palves@redhat.com> wrote:

>?I could claim the
> opposite, that generic code in infrun shouldn't know about any of this
> juggling, that it should work with whatever uiout is current. ?Imagine if a
> python uiout ever comes through (it has been discussed to add one). ?Not sure
> always flipping the current uiout to the cli uiout like that would
> be a good idea -- seems like something that would get in the way.

FWIW the attachments to PR 11688 should probably be able to see if
this is an issue (I would also imagine it seems like it would)

derail:
what's keeping it from being submitted is some relatively minor issues
that have a large testing/modification girth,

 I was considering posting a plan for a way to allow this to be done piecemeal,
so here goes.

the main issue is that the current ui-out types do not contain
adequate information to allow one to pre-allocate a python object of
e.g. a dictionary or a list, instead we must wait after starting the
list or dictionary until the first item is added to know if it is
key/value or merely values,

in some extreme cases this leads to (currently) having to promote
things from none, strings to lists of strings etc.

this means we need to add some uiout_types (which for the mi uiout we
would handle exactly the same as currently) but for py uiout would
allow us to preallocate the correct object type.

one way to do this without auditing every command is to throw a python
exception in py uiout rather than doing said promotion, and just
fixing the uiout type as we run across broken commands/options.

this means there may not be parity between mi and python immediately,
but it would expedite the process since, i have currently rather
successfully avoided completing/starting a complete command/option
audit, there are more specific details in the PR 11688.


IMO there is 3 options:
a) musical chairs typing (as currently implemented)
b) stable typing + complete audit
c) stable typing + throw exceptions/fix as we find issues

so I guess what i'm proposing is C.

anyhow please let me know if there are any objections to such laziness.