[omniORB] Attributes in omniORBpy

[Leandro Fanzone]

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
>
>  
>