diff mbox series

[v2] qapi: provide a friendly string representation of QAPI classes

Message ID 20230922153257.352911-1-berrange@redhat.com (mailing list archive)
State New, archived
Headers show
Series [v2] qapi: provide a friendly string representation of QAPI classes | expand

Commit Message

Daniel P. Berrangé Sept. 22, 2023, 3:32 p.m. UTC
If printing a QAPI schema object for debugging we get the classname and
a hex value for the instance:

  <qapi.schema.QAPISchemaEnumType object at 0x7f0ab4c2dad0>
  <qapi.schema.QAPISchemaObjectType object at 0x7f0ab4c2dd90>
  <qapi.schema.QAPISchemaArrayType object at 0x7f0ab4c2df90>

With this change we instead get the classname and the human friendly
name of the QAPI type instance:

  <QAPISchemaEnumType:CpuS390State>
  <QAPISchemaObjectType:CpuInfoS390>
  <QAPISchemaArrayType:CpuInfoFastList>

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---

v1 was two & half years ago:

  https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg01645.html

 scripts/qapi/schema.py | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Markus Armbruster Oct. 18, 2023, 10:54 a.m. UTC | #1
Daniel P. Berrangé <berrange@redhat.com> writes:

> If printing a QAPI schema object for debugging we get the classname and
> a hex value for the instance:
>
>   <qapi.schema.QAPISchemaEnumType object at 0x7f0ab4c2dad0>
>   <qapi.schema.QAPISchemaObjectType object at 0x7f0ab4c2dd90>
>   <qapi.schema.QAPISchemaArrayType object at 0x7f0ab4c2df90>
>
> With this change we instead get the classname and the human friendly
> name of the QAPI type instance:
>
>   <QAPISchemaEnumType:CpuS390State>
>   <QAPISchemaObjectType:CpuInfoS390>
>   <QAPISchemaArrayType:CpuInfoFastList>

This gains the QAPI name (good), but loses the address.  The actual
address is rarely useful (when it is, you're deep in Python innards;
good luck, you'll need it).  Except they let me see which objects are
the same, and which are different.  Could that be preserved without
trouble somehow?

> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>
> v1 was two & half years ago:
>
>   https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg01645.html

Was it my fault?  If yes, I apologize.

>  scripts/qapi/schema.py | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
> index 231ebf61ba..20ffacbdf0 100644
> --- a/scripts/qapi/schema.py
> +++ b/scripts/qapi/schema.py
> @@ -73,6 +73,12 @@ def __init__(self, name: str, info, doc, ifcond=None, features=None):
>          self.features = features or []
>          self._checked = False
>  
> +    def __repr__(self):
> +        if self.name is not None:
> +            return "<%s:%s>" % (type(self).__name__, self.name)
> +        else:
> +            return "<%s>" % type(self).__name__
> +
>      def c_name(self):
>          return c_name(self.name)
Daniel P. Berrangé Oct. 18, 2023, 11:05 a.m. UTC | #2
On Wed, Oct 18, 2023 at 12:54:28PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > If printing a QAPI schema object for debugging we get the classname and
> > a hex value for the instance:
> >
> >   <qapi.schema.QAPISchemaEnumType object at 0x7f0ab4c2dad0>
> >   <qapi.schema.QAPISchemaObjectType object at 0x7f0ab4c2dd90>
> >   <qapi.schema.QAPISchemaArrayType object at 0x7f0ab4c2df90>
> >
> > With this change we instead get the classname and the human friendly
> > name of the QAPI type instance:
> >
> >   <QAPISchemaEnumType:CpuS390State>
> >   <QAPISchemaObjectType:CpuInfoS390>
> >   <QAPISchemaArrayType:CpuInfoFastList>
> 
> This gains the QAPI name (good), but loses the address.  The actual
> address is rarely useful (when it is, you're deep in Python innards;
> good luck, you'll need it).  Except they let me see which objects are
> the same, and which are different.  Could that be preserved without
> trouble somehow?

It appears the hex value comes from  'id(obj)', so yes, I can
insert the same hex value into the new representation.

> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >
> > v1 was two & half years ago:
> >
> >   https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg01645.html
> 
> Was it my fault?  If yes, I apologize.

No, I forgot about it until I was moving old branches from my previous
laptop to my new laptops :-)

> 
> >  scripts/qapi/schema.py | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
> > index 231ebf61ba..20ffacbdf0 100644
> > --- a/scripts/qapi/schema.py
> > +++ b/scripts/qapi/schema.py
> > @@ -73,6 +73,12 @@ def __init__(self, name: str, info, doc, ifcond=None, features=None):
> >          self.features = features or []
> >          self._checked = False
> >  
> > +    def __repr__(self):
> > +        if self.name is not None:
> > +            return "<%s:%s>" % (type(self).__name__, self.name)
> > +        else:
> > +            return "<%s>" % type(self).__name__
> > +
> >      def c_name(self):
> >          return c_name(self.name)
> 

With regards,
Daniel
Markus Armbruster Oct. 18, 2023, 11:52 a.m. UTC | #3
Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Oct 18, 2023 at 12:54:28PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > If printing a QAPI schema object for debugging we get the classname and
>> > a hex value for the instance:
>> >
>> >   <qapi.schema.QAPISchemaEnumType object at 0x7f0ab4c2dad0>
>> >   <qapi.schema.QAPISchemaObjectType object at 0x7f0ab4c2dd90>
>> >   <qapi.schema.QAPISchemaArrayType object at 0x7f0ab4c2df90>
>> >
>> > With this change we instead get the classname and the human friendly
>> > name of the QAPI type instance:
>> >
>> >   <QAPISchemaEnumType:CpuS390State>
>> >   <QAPISchemaObjectType:CpuInfoS390>
>> >   <QAPISchemaArrayType:CpuInfoFastList>
>> 
>> This gains the QAPI name (good), but loses the address.  The actual
>> address is rarely useful (when it is, you're deep in Python innards;
>> good luck, you'll need it).  Except they let me see which objects are
>> the same, and which are different.  Could that be preserved without
>> trouble somehow?
>
> It appears the hex value comes from  'id(obj)', so yes, I can
> insert the same hex value into the new representation.

I'd appreciate that.

>> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
>> > ---
>> >
>> > v1 was two & half years ago:
>> >
>> >   https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg01645.html
>> 
>> Was it my fault?  If yes, I apologize.
>
> No, I forgot about it until I was moving old branches from my previous
> laptop to my new laptops :-)

Puh!

[...]
diff mbox series

Patch

diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
index 231ebf61ba..20ffacbdf0 100644
--- a/scripts/qapi/schema.py
+++ b/scripts/qapi/schema.py
@@ -73,6 +73,12 @@  def __init__(self, name: str, info, doc, ifcond=None, features=None):
         self.features = features or []
         self._checked = False
 
+    def __repr__(self):
+        if self.name is not None:
+            return "<%s:%s>" % (type(self).__name__, self.name)
+        else:
+            return "<%s>" % type(self).__name__
+
     def c_name(self):
         return c_name(self.name)