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 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/CAPGFgA0yx74NaTzj3imyXVn4AdXJ6S6qyU1vpx6d2XKCdWGJyw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
