how to break up my script into modules

[s...@weacceptyou.com]

Hey all,

i have finished a large script which effectively builds a new mesh topology from an underlying sculpt mesh. My script is currently approaching the 3000 line mark. Its is hard to navigate and i wanted to break into modules which i can trigger off from a main script.

i want to have one script organised like this:

1) do hands (call hands creation modules)
2) do arms (call arms module)
3) do legs (call legs module)
4) do feet (call feet module)
5) do torso (call torso module)
6) do head (call head module)

7) combine surfaces and merge verts

i understand the principle of modules but i just wanted to make sure if this is a smart way to organise it. And if someone could just give me a basic set of steps i could take to achieve it. Im not clear whether everything needs to be a class for example.

And there are common functions which each module in turn needs to call in order to build their meshes, and i don't know if the modules will be able to see the functions they require. I assume if i want to keep the main script minimal i will need all those smaller functions i created (that each module would need to access) in their own module.

then there are also 'packages' and whether this is a better solution?

sorry a bit long, but thought it best i really understand this before i spend days sifting through this script and creating more problems for myself in the end.

thanks alot guys,
Sam

[simonp91]

Hi Sam.
What you want to make is basically a python 'package' . I.e, a dir with a sensible name, containing the seperate scripts ('modules'), plus an __init__.py file. The folder (package) is then its own import call as long as it is in your python path. So lets say your package/folder is called 'character' :

In this 'character' folder you have a blank text file called __init__.py which can serve further purposes, but essentially is there to recognise this package on import. Now its all down to namespaces. So you can put a script in here called 'hands.py' for example.

Your call to a function in your 'hands' module would be something like :

Import character as char
Import char.hands
char.hands.buildHands()

In here you can import legs, arms or anything else in the hands module or whatever. But you can also use a userSetup.py within your 'character' package. Put all your imports there if you like. So when you :
Import character
It will import all modules as per names/imports you've specified in your userSetup automatically, that you can now refer to directly. Just don't loose track of your designated namespaces and be consistant with them if you don't want confusion in module-to-module function calls.

As for class's...it is not imperritive to make everything you do object oriented. Classes are primarily a tool for instanciatian and inherritance. Maybe slightly overkill for just running functions that perform simple algorythms. Depends how you prefer to script and if the task your completing requires it.

Hope that helps

Simon

Sent from my iPhone

> --
> 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 python_inside_m...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/605c97e4-0835-4054-a9a2-0aaa53036828%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[s...@weacceptyou.com]

wow thanks alot Simon, that was exactly the answer i was looking for. nice one!

Sam

[s...@weacceptyou.com]

oh there was one other thing. Where would gui code be in this package? - Would that be another module like the others that gets called first?

thanks
Sam

[simonp91]

It would be wherever makes sense to you. I personally like to have categorised packages within the main package...i.e sub-packages. UI stuff is typically in a UI sub package for me. I also like to keep a lib package within each sub-package where I put all modules relevant to the sub-package that are not platform specific. For example most naming functions can live in naming modules within the lib foldee/package of the naming sub package as most naming functions are purely pythonic and nothing to do specifically with maya or any other platform.

Simon

Sent from my iPhone

> --
> 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 python_inside_m...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/bb9e210b-ac24-4f28-9280-94d4f9734368%40googlegroups.com.

[simonp91]

Your very welcome :-)

Sent from my iPhone

> On 19 Apr 2016, at 22:33, s...@weacceptyou.com wrote:
>
> wow thanks alot Simon, that was exactly the answer i was looking for. nice one!
>
> 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 python_inside_m...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/d7c5a33c-1d37-4ff6-8735-9e0ccb398c0d%40googlegroups.com.

[s...@weacceptyou.com]

cheers, got it!

Sam

[Fredrik Averpil]

I'd also recommend that you don't inherit class objects everywhere, just because the sake of inheriting - or you may end up with inheritance resolution errors. Python kind of seems, at first glance, to want you to design your stuff that way. At least that was how I was taught Python...

Instead I'd create libraries and import where needed instead of inheriting them. It's an easy pit fall (in my opinion) when you start out structuring a larger Python application.

Also, install the flake8 linter in your favorite editor. This'll warn you of common mistakes too and make you appreciate PEP-8.

Cheers!

On Wed, Apr 20, 2016 at 12:15 AM <s...@weacceptyou.com> wrote:

cheers, got it!

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 python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/8c8e0df4-aaf7-4975-8602-894699bec098%40googlegroups.com.

[s...@weacceptyou.com]

thanks Frederik i will look into using libraries. cheers for the heads up

Sam

[Marcus Ottosson]

Just so we don't get confused; Python does not have any notion of a "library", just modules and packages. A "library" may be to some a convention, indicating that it is mainly used together with another module/package. It's also sometimes referred to as helper or utility module/package.

Other languages on the other hand do have libraries which are different from source files. If you end up googling for libraries, those are what you might find.

[Justin Israel]

On Wed, 20 Apr 2016 8:35 PM <s...@weacceptyou.com> wrote:

thanks Frederik i will look into using libraries. cheers for the heads up

Also watch this 

https://youtu.be/o9pEzgHorH0

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 python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/8f0287da-b45d-41e2-b80b-a1d7e4d35e73%40googlegroups.com.

[Fredrik Averpil]

> Just so we don't get confused

Ah, yes. Sorry. Thanks for correcting me on that. Could be very confusing, I agree.

Cheers,

Fredrik

[sam williams]

thanks guys alot to think about ;)

--
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/S6O23DTbk5w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMV%2BP3uFh8kMsgMJasewEW6aLROUjFc-0%3DVXuAcdV0%2BNQ%40mail.gmail.com.