Email Re: [Fwd: Re: [Python-projects] pylint failure?]

Alessandro Caproni wrote:
> Hi Dave,
> I have investigated 2 errors reported by pylint while checking 
> ACSImpl/Enum.py and acstimeSWIG.py. After some time I sent an email to 
> the pylint developer and here you can see their answer.
> 
> What do you think? I think that acstimeSWIG.py is autoatically generated 
> by SWIG. Is it? In this case we can do nothing but waiting for they to 
> fix the bug.
Yes, acstimeSWIG.py i created by SWIG.

> What about ACSImpl/Enum.py?
See my response below.


> -------- Original Message --------
> Subject:  Re: [Python-projects] pylint failure?
> Date:  Wed, 9 Feb 2005 16:44:39 +0100
> From:  Sylvain Thénault <Sylvain.Thenault@logilab.fr>
> Reply-To:  Sylvain Thénault <Sylvain.Thenault@logilab.fr>
> To:  Alessandro Caproni <acaproni@eso.org>
> CC:  python-projects@www.logilab.org
> References:  <420A2AEE.8030307@eso.org>
> 
> Hum, you've actually hit a bug in pylint. I'll try to fix this to avoid
> pylint to choke, but I guess I won't be able to do much more, such as
> resolving your class'parent, because of the "eval" call. This is the 
> first time I see this kind of construct to define a class, and I find 
> it, well... at least unreadable ;)
> 
> The best suggestion I have is to avoid using eval in the parents list
> of your class. Maybe can you explain us what are you trying to acheive
> so we can help you to get something more clean and clear.
> 
Hello, the reason there is an eval in the parents list is because this 
snippet of code is used in the context of a dynamic class generator. 
This is necessary because:
1) While enumName is guaranteed to be a real class, we do not know it's 
name until run-time. Also, there are many different values for enumName 
that will be used.
2) The parent class is dynamically generated itself (i.e., it's a CORBA 
servant stub).
3) The parent class for one enumName value contains members/methods that 
are ~70% different (in their names as well as their values) from another 
enumName value. The similar methods/members are inherited from Penum.
4) Because tClass is implementing a CORBA object; we must use 
inheritance (i.e., it's not good enough to dynamically add 
methods/members to a tClass object) or use proxy objects.

So in summary, enumName is for the most part an abstract interface, 
Penum implements the abstract methods of enumName, and there are many 
different instances of tClass as a direct result of there being many 
different values for enumName.

Another possibility I looked at was removing inheritance from the 
enumName class within tClass and then dynamically adding it to a tClass 
object after it has been instantiated like so:
tList = list(self.__class__.__bases__)
tList.insert(0, eval(enumName, tGlobals, tLocals))
         self.__class__.__bases__ = tuple(tList)
but of course this affects the entire tClass and not just the object.

If you can offer any suggestions, I'd love to hear them.

Dave

PS
See the attached code



-- 
There are 10 types of people in the world. Those that understand binary 
and those that don't.