thanks Justin, so inside the configure module, which you help me setup a few weeks ago. is the class which sets up all the variables and then returns just the class instance which contains all the variables as one keyword right? like:
'attribute.limb_num' 'attribute.curve_num' 'attribute.current_surface' so then i can just return 'attribute' to the main 'run' script. and these initialised variables get used throughout the script. so in my 'run' module there is a call to another module 'circle_configure', using the returned 'attribute' variables from the 'configure' module. This module which deals with creating circles for lofting geometry for the fingers of my character. Inside the 'circle_configure' module there is a bunch of code which creates new variables that are specific to the current finger that the script is working on (there is a loop which goes through each finger in the character), like 'circle_num' or 'crv_pnt1' and ''limb_vec' etc. This information is created for the current finger and then i need to send this newly created info to the module which fires rays and returns collision points on the mesh of my character. fire_circles.execute(circle_counter,limb_counter,curr_circ_center,limb_vec,crv_pnt1,crv_pnt2) is this the correct way to use the call to another module within a module. Just send it the required variables as arguments? and then return values from that module and store it in a new variable like: collisionPoints=fire_circles.execute(circle_counter ,limb_counter,curr_circ_center,limb_vec,crv_pnt1,crv_pnt2) Then use the collisionPoints variable as the argument in the call to the next module in my script? loft_surfaces(collisionPoints)? this is what i mean by keeping track of the variables and passing them onto the next module. Maybe its fine and this is what i need to be doing, but i just wanted to be sure on it thanks, Sam On 18 June 2016 at 22:20, Justin Israel <[email protected]> wrote: > > > On Sun, 19 Jun 2016 6:30 AM <[email protected]> wrote: > >> hi Justin, >> >> sorry let me explain more clearly. I have a package which contains 3 >> modules (seperate python files) and a subpackage which contains all the >> utility modules (6 other python files, like 'subdivide_curves' and >> 'fire_circles' etc). >> >> in the main package the 3 modules 'createGui' which loads my GUI, one >> 'configure' which sets up all the required variables for my program and >> another 'run' which actually gets called when the user runs the program >> through the GUI. >> > > Sorry for getting it wrong earlier. Without enough info, your example just > kept looking like functions. Thanks for explaining this setup. > > >> Inside 'run' it basically has all of my modules loaded in (that are being >> used directly in 'run' like this: >> >> ------------------------------------------- >> >> import samDev.rigging.TOPOCOAT.configure as configure >> reload(configure) >> import samDev.rigging.TOPOCOAT.utility_functions.subdivide_curves as >> subdivide_curves >> reload(subdivide_curves) >> import samDev.rigging.TOPOCOAT.utility_functions.general as general >> reload(general) >> import samDev.rigging.TOPOCOAT.utility_functions.webbing as webbing >> reload(webbing) >> import samDev.rigging.TOPOCOAT.utility_functions.circle_configure as >> circle_config >> reload(circle_config) >> >> --------------------------------------- >> >> and then there is a main function which just calls the required modules >> one after the other using the variables returned from the 'configure' >> module. >> >> eg. 'subdivide_curves.execute(configured_curves)' >> >> The problem i think when a module is called which then itself creates new >> variables (specific to that module) and calls another module and i have to >> track the current variables' state at that point and feed those modified >> variables into the module call. >> > > This is the bit where I am not able to follow without more examples. When > you say your module creates new variables when you call a function, where > does it store them? And how are you "tracking" them? Can you show a small > example of what is going on here? > > This sounds like the opposite situation of a thread last week where > classes were being used without tracking much state. In your your case, > from what you describe it sounds like you do need an instance of a class > that can track state as you call methods. You shouldn't need to track new > variables that are being created in another module, just to pass them to > functions of that module. Kinda seems like a code smell. Does your calling > module even care care about the details of these variables other than > needing to pass them to the other module where they live? Is it just an > implementation detail and your calling module is just acting like a proxy > for passing the variables around? > > If you organise a class in the subdivide module which accepts a config > once in its constructor, then you can work with an instance of that class > that is configured and can track it's own implementation details between > method method calls. > > I hope that seemed applicable to your situation. > > > > Like inside the module 'circle_configure' the script calls the module >> 'general' which has a function that fires rays and return collision points. >> but before it calls it i have to figure out all the variables it requires >> from the 'subdivide_curves' module and feed them into the module call: >> >> fire_circles.execute(circle_counter,limb_counter,curr_circ_center,limb_vec,crv_pnt1,crv_pnt2) >> >> when this was all one script everything linked up obviously. But as im >> splitting things up im finding it tedious to feed information from one >> module into the next one. And im not sure if im setting this up sensibly. >> > > Maybe it all worked better as one script because you are using global > variables? If that is the case, yes it would make it harder to split things > up because there isn't enough encapsulation. > Not sure until we see how those variables are created. > > >> I hope this is clearer? sorry am a bit lost here >> >> thanks alot Justin, >> Sam >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/193f7cdf-2348-4071-b934-8dcb826a9685%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "Python Programming for Autodesk Maya" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/python_inside_maya/SvBxVxv7uog/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0yx74NaTzj3imyXVn4AdXJ6S6qyU1vpx6d2XKCdWGJyw%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0yx74NaTzj3imyXVn4AdXJ6S6qyU1vpx6d2XKCdWGJyw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CA%2BGceHXc9haohTfbA-8yDPWTL5NQcjPP6ZD3o-L9byUsNmenAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
