<p><br>
On Feb 17, 2014 7:24 PM, ""André Walker-Loud &<a href="mailto:lt%3Bwalksloud@gmail.com">lt;walksloud@gmail.com</a>>"" <<a href="mailto:walksloud@gmail.com">walksloud@gmail.com</a>> wrote:<br>
><br>
> Question 1:<br>
> Is there a better way to accomplish (my hopefully clear) goals?</p>
<p>I'm not sure that there is given the constraints you're under from the third party function.<br></p>
<p>> Question 2:<br>
> In method 1, is there a way to combine the two classes, or is the FunctionStruct necessary? I want to do something *like*<br>
><br>
> self.func_code.co_varnames = tuple(['c_%i'%(i) for i in range(len(pars))])<br>
> self.func_code.co_argcount = len(pars)<br>
><br>
> but I was not sure how to first define ‘self.func_code’. Can you define it as an empty container somehow (is that the right way to describe it)?</p>
<p>I'm not sure about the details of this. Maybe Eryksun will chime in there...</p>
<p>> Question 3:<br>
> The 2nd method is in some sense simpler - I just hack together a string, but I need to use global variables, which I know can be problematic. Which method, 1 or 2, is in general better? One answer, is whatever works, but I am trying to also improve my programming skills, so I am wondering from a software perspective, which is preferable?</p>
<p>Either solution if it works for this case seems fine to me. I'd be inclined to in for the simpler compile/exec approach.</p>
<p>The "right" solution is to change the interface of the third party function. It is poorly designed and should not be inspecting those function attributes or it should at least provide an option for you to provide that information in a different way. Assuming it's open source you could try sending a patch. In the mean time you could copy that code and modify it to suit your purposes.<br>
</p>
<p>Oscar</p>