[omniORB] Attributes in omniORBpy

[Kevin Wooten]

Sorry about that I only tested the getter, never tried setter, which
appears to overwrite the property object with whatever value you set it
to, not treating it "special". 

Anyway, I tried to fix the problems in omniPy, but did not get it
working as of yet. It appears that the code is using PyClass_Check, to
guarantee and object is of type "class", which is the old style class. I
tried changing all occurances of this to PyType_Check, and putting
"__metaclass__=type" at the beginning of most of the python files.
Setting "__metaclass__" in a module changes the base type of all class
definitions in that module that do not derive from some type. This part
appears to work correctly as it solves the problem of the assert's
failing.

Somewhere else the code dumps, I believe this is because of an
assumption that those objects are old style classes but I have not
tracked it down, still working.

-----Original Message-----
From: Leandro Fanzone [mailto:leandro@hasar.com] 
Sent: Friday, November 22, 2002 8:04 AM
To: Kevin Wooten
Cc: omniorb-list@omniorb-support.com
Subject: Re: [omniORB] Attributes in omniORBpy

I have already seen that, but the problem is that the "property" keyword

requires the new Python 2.2 class style, id est, the class "test" in 
your example must subclass the builtin class "object" in order to make 
the "property" keyword work. I tried to make any generated class from 
IDL to subclass "object" and python segfaults, I don't know why. As in 
the end all generated classes subclass CORBA.Object, I tried to make 
that class subclass "object", but that violates an assertion (from 
omnipy.cc, line 362, "PyClass_Check(omniPy::pyCorbaContextClass)"), so I

guess it is not that straightforward, for some reason.
A curious thing: in your example (classic style, not subclassing 
"object") the getter works fine, but the setter doesn't, and the same 
thing occurs naturally in the stubs generated by your attached
python.py.

Leandro Fanzone

Kevin Wooten wrote:

>Even better Python 2.2 has descriptors that support simple get/set
>properties e.g.
>
>	class test:
>		def getProp(self):
>			return self.__prop
>		def setProp(self,val):
>			self.__prop = val
>
>		#define a property
>		prop = property( getProp, setProp, None, "a property" )
>		# The setter (second parameter) can be None for
>read-only 			# attributes
>		# The third parameter is the name of an optional deleter
>for
>		# use in "del test.prop" statements, and the last is a
>doc
>		# string
>
>These additions are sufficiently non-intrusive and could be added
>without introducing problems in the mapping ( since the only token it
>introduces is the name of the attribute itself ). This is entirely up
to
>Duncan though.
>
>I have already altered my omniidl's python backend to emit these
>properties.
>The file is attached. It should replace the python.py file in your
>omniidl_be directory.
>
>-----Original Message-----
>From: Leandro Fanzone [mailto:leandro@hasar.com] 
>Sent: Thursday, November 21, 2002 11:25 AM
>To: omniorb-list@omniorb-support.com
>Subject: [omniORB] Attributes in omniORBpy
>
>Attributes in omniORBpy are mapped as methods (_get_/_set_). Though I 
>know the OMG specification says it must be so, I thought that it would 
>be useful to also have a direct mapping using the 
>__setattr__/__getattr__ technique; these methods could call the 
>"official" methods using exec, for example. In this way we could access

>the attributes from a client in a more straightforward fashion than 
>calling methods. I'm sure you already gave this some thought; did you 
>find something that prevented this from being done?
>Thank you in advance,
>
>Leandro Fanzone
>
>_______________________________________________
>omniORB-list mailing list
>omniORB-list@omniorb-support.com
>http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>  
>