scripts/qapi/schema.py | 6 ++++++ 1 file changed, 6 insertions(+)
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(+)
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)
--
2.41.0
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)
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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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! [...]
© 2016 - 2024 Red Hat, Inc.