[Maya-Python] Optimise this: Hierarchy from String

219 views
Skip to first unread message

Marcus Ottosson

unread,
Sep 15, 2016, 1:36:26 AM9/15/16
to python_in...@googlegroups.com

Hi all,

I’m putting together a minor helper function for establishing a transform hierarchy within Maya but am not yet satisfied with the implementation.

It works like this.

hierarchy_from_string("""\
rig
    implementation
        geometry
        skeleton
    interface
        controls
        preview
""")

Resulting in this.

Inline images 1

The idea then is to start making nodes and move them into their home via cmds.parent().

But my implementation so far is fairly limited.

  1. Doesn’t take existing nodes into account
  2. Breaks on empty lines
  3. Can overall be made more elegant, I think

So my question to you is, how would you write this?

def hierarchy_from_string(hierarchy):
    parents = {}

    for line in hierarchy.split("\n"):
        if not line:
            continue

        name = line.strip()
        padding = len(line[:-len(name)])
        parents[padding] = name

        name = cmds.createNode("transform", name=name)

        for parent in sorted(parents):
            if parent < padding:
                cmds.parent(name, parents[parent])

Thanks for chiming in!

​
--
Marcus Ottosson
konstr...@gmail.com

Eric Thivierge

unread,
Sep 15, 2016, 9:32:35 AM9/15/16
to python_in...@googlegroups.com
Isn't this sort of thing what YAML and JSON were created for? Human readable formats that have tools to iterate over hierarchies of data?

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODMBoLY%2Bcc_%3DK58NKmaPt0D%3DBKqdwL%2B%3DRFwLLH2j8831A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

marcus....@framestore.com

unread,
Sep 15, 2016, 3:15:37 PM9/15/16
to Python Programming for Autodesk Maya
Snarky, but thanks for chiming in.

Justin Israel

unread,
Sep 15, 2016, 3:18:35 PM9/15/16
to Python Programming for Autodesk Maya


On Fri, 16 Sep 2016, 7:15 AM <marcus....@framestore.com> wrote:
Snarky, but thanks for chiming in.

Maybe. Maybe not. 
It seems to address your 2nd and 3rd points, by asking if you would consider changing the input string format to a style that would give you hierarchy processing for free. 


--
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/b96da911-316a-4815-83e0-d359fe1b6ea9%40googlegroups.com.

Eric Thivierge

unread,
Sep 15, 2016, 3:25:11 PM9/15/16
to python_in...@googlegroups.com
Definitely didn't mean to be snarky. I could have worded it differently sure. I guess I was trying to get more info on why JSON or YAML wouldn't be a solution for you.

--------------------------------------------
Eric Thivierge
http://www.ethivierge.com

On Thu, Sep 15, 2016 at 3:18 PM, Justin Israel <justin...@gmail.com> wrote:


On Fri, 16 Sep 2016, 7:15 AM <marcus.ottosson@framestore.com> wrote:
Snarky, but thanks for chiming in.

Maybe. Maybe not. 
It seems to address your 2nd and 3rd points, by asking if you would consider changing the input string format to a style that would give you hierarchy processing for free. 

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0-U9ovtaBUx4tjgB%2Bx55FKmWM_zHdsW2F85UJ%3DAtyFjw%40mail.gmail.com.

Marcus Ottosson

unread,
Sep 16, 2016, 1:41:48 AM9/16/16
to python_in...@googlegroups.com

Fair enough!

The resulting function is going into a code example that I’m trying to make as readable as possible.

I find the readability of this approach less distracting and less motivated than, say, this.

hierarchy_from_json({
    "rig": {
        "implementation": {},
        "geometry": {},
        "skeleton": {},
        "interface": {
            "controls": {},
            "preview": {},
        }
    }
})

And YAML would require either my tiny example to include it, or for the user to install it.

Apart from that, and the reason I’m here, was that I was interested in seeing how others would approach a string processing challenge of this stature. I expected to find it inspiring and spark ideas with others and myself.

​

Alok Gandhi

unread,
Sep 16, 2016, 4:04:42 AM9/16/16
to python_in...@googlegroups.com
IMHO, parsing the string is just a matter of administrative logic and should not be bothered with when focussing on the business logic (which, in this case, is recreating the hierarchy).

Sure JSON, YAML, and XML(ugly) are a few options to choose from for parsing the string. In the end, It is just a detail to get the data, nothing more, nothing less.

What is important is how we deal with that data in the most efficient, optimized and readable way.

So here is my implementation, parsing your original indented string. This definitely covers your points 1 and 2.  3 is a matter of opinion and is subjective.

Few things to note:
  • Right in the beginning, we parse the string in a single line, keeping the administrative logic out from the rest of our business code. You can easily replace this single line with whatever parser you want.
  • I am using `namedtuple` for readability they are lightweight and require no more memory than regular tuples.
  • `bisect` uses a basic bisection algorithm, an improvement over the common approach for finding an insertion point in a sorted list without having to sort it again.
  • This completely eliminates multiple calls to parent() as in your original implementation. For each line in the input string, we parent only once, no need to go back up or down in the hierarchy with multiple if-elif-else. This is more efficient and straight forward.
  • Handles multiple hierarchies starting from the root (which your version also covered I think)
  • Space characters are not a problem on an empty line(In my example, I have deliberate space chars to demonstrate that). On that note, please note that I am using line.strip(' ') instead of line.strip(), the reason being you can still parse escape characters like \r \t \n etc., strip() eats them up as they are whitespaces as well.

----------------------------------------------------------
from collections import namedtuple
from bisect import bisect_left

import pymel.core as pm


def hierarchy_from_string(hierarchy):
    NodeInfo = namedtuple('NodeInfo', 'node indent')
    nodeInfos = []
    for nodeName, currIndent in ((line.strip(' '),
                                  len(line) - len(line.lstrip(' ')))
                                 for line in hierarchy.split("\n")
                                 if line.strip()):

        node = (pm.ls(nodeName)[0] if pm.ls(nodeName)
                else pm.createNode('transform', name=nodeName))

        parentIndex = bisect_left([nodeInfo.indent for nodeInfo in nodeInfos],
                                  currIndent)

        parentNode = (nodeInfos[parentIndex - 1].node
                      if parentIndex - 1 >= 0 else None)

        nodeInfo = NodeInfo(node=node, indent=currIndent)

        if parentIndex < len(nodeInfos):
            nodeInfos[parentIndex] = nodeInfo
        else:
            nodeInfos.append(nodeInfo)

        pm.parent(node, parentNode)


hierarchy_from_string("""\
rig
    implementation
        geometry
        skeleton
    interface
        controls
        preview
foo
    bar
    
        baz   
      
            alice
            bob
""")

- Alok

Alok Gandhi

unread,
Sep 16, 2016, 4:49:52 AM9/16/16
to python_in...@googlegroups.com
On second thought, we would NOT like to parse escape characters as maya would complain later:

   for nodeName, currIndent in ((line.strip(),
                                  len(line) - len(line.lstrip()))

                                 for line in hierarchy.split("\n")
                                 if line.strip()):
--

Marcus Ottosson

unread,
Sep 16, 2016, 4:54:40 AM9/16/16
to python_in...@googlegroups.com
Thanks Alok, that's just what I was looking for.

I was just about to mention that about the escape characters, a bare `strip()` works to our advantage here.

Use of bisect is interesting, I'll have to dig deeper into that.

Marcus Ottosson

unread,
Sep 16, 2016, 8:44:23 AM9/16/16
to Python Programming for Autodesk Maya
Ok, Alok, I had a closer look at your example and the bisect module in Python.

In my example, a dict replaces bisect. The dict is limited, in that once a parent at the same level as an above parent appears, the above parent vanishes from consideration. But in this case, maybe that works to our advantage? Could you tell me about your motivation for using bisect?

Alok Gandhi

unread,
Sep 16, 2016, 10:01:48 AM9/16/16
to python_in...@googlegroups.com
Hi Marcus,

My objective was simple, parenting is the main focus and it should be done  once and only once for each node in the hierarchy. To achieve this, during each iteration the node should have knowledge about his parent just by knowing its position (indent).

I did not want complex processing of saving states and whole trees and then lookup up and down. The node should have a place (the tuple list) to look for its parent. It simply asks this question - I have this position, who is my parent. This is typically looking for an insertion point in an array and bisect was a perfect candidate for these requirements.

After finding the parent, the node attaches itself to the list replacing the current node at that position so that preceding nodes can find it as a parent when required.

Using a dict is a better option just for the reason of O(1) lookup times, but then you should do this lookup only once for each node and not iterate through each key and then deep inside it until some condition is reached. To me, that is a bit complex.

On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson <konstr...@gmail.com> wrote:
Ok, Alok, I had a closer look at your example and the bisect module in Python.

In my example, a dict replaces bisect. The dict is limited, in that once a parent at the same level as an above parent appears, the above parent vanishes from consideration. But in this case, maybe that works to our advantage? Could you tell me about your motivation for using bisect?

--
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_maya+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Marcus Ottosson

unread,
Sep 16, 2016, 10:04:19 AM9/16/16
to python_in...@googlegroups.com
> but then you should do this lookup only once for each node and not iterate through each key and then deep inside it until some condition is reached. To me, that is a bit complex.

Ah, yes that is true. I did not think of that. Thanks for pointing that out.

As someone who isn't terribly familiar with bisect, how does bisect achieve this if not by traversing each node in turn and returning the first found, like how the dict is being used currently?

On 16 September 2016 at 15:01, Alok Gandhi <alok.ga...@gmail.com> wrote:
Hi Marcus,

My objective was simple, parenting is the main focus and it should be done  once and only once for each node in the hierarchy. To achieve this, during each iteration the node should have knowledge about his parent just by knowing its position (indent).

I did not want complex processing of saving states and whole trees and then lookup up and down. The node should have a place (the tuple list) to look for its parent. It simply asks this question - I have this position, who is my parent. This is typically looking for an insertion point in an array and bisect was a perfect candidate for these requirements.

After finding the parent, the node attaches itself to the list replacing the current node at that position so that preceding nodes can find it as a parent when required.

Using a dict is a better option just for the reason of O(1) lookup times, but then you should do this lookup only once for each node and not iterate through each key and then deep inside it until some condition is reached. To me, that is a bit complex.
On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson <konstr...@gmail.com> wrote:
Ok, Alok, I had a closer look at your example and the bisect module in Python.

In my example, a dict replaces bisect. The dict is limited, in that once a parent at the same level as an above parent appears, the above parent vanishes from consideration. But in this case, maybe that works to our advantage? Could you tell me about your motivation for using bisect?

--
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_maya+unsubscribe@googlegroups.com.



--

--
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_maya+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Alok Gandhi

unread,
Sep 16, 2016, 10:57:05 AM9/16/16
to python_in...@googlegroups.com
> How does bisect achieve this if not by traversing each node in turn and returning the first found, like how the dict is being used currently?

In all fairness, there is no way, this can be achieved without some sort of iteration. Bisect is efficient because it implements the binary search algorithm which runs in O(logN) time in the worst case. For a few hundred or maybe even few thousand nodes this is better than doing a for loop for finding a key. The key point is the binary search. In a for loop you go through each key of the dictionary from top to bottom, in binary search, you start from the middle and halve the search domain in each iteration, which is far more efficient. Not to mention, running a for loop inside another for loop makes this O(n**2)

Dict (hash table) is good only if you know the key beforehand, otherwise, you will have to implement your own logic to find the right key, value pair and that logic either bloats up your code and/or sometimes makes it less efficient in terms of both memory and/or performance. And then python has these little gotchas when it comes to optimization (simple things like using `xrange` over `range`, `izip` over `zip`, even using `% (a,)` in place of `% a` make a considerable difference), which might be overlooked, if either you don't know them or you don't have time to polish your code.

For me bisect brings two distinct advantages to the table:
1. A compiled efficient fast search code that has been optimized to a certain level (being a part of core python library) compared to my own logic that might or might not be the fastest, efficient thing.
2. A neat single line call in my code instead of a for loop and maybe other conditionals, control flows, lookups etc. with my own logic - readability does count.

Also, not an answer to your original question but -
I did a dry run of your code replacing the parenting with a simple print like '{0} ->{1}'.format(parent, child). I saw that parenting was done multiple times starting from a top parent and going down to the desired level:
level1->child, level2->child, level3->child etc. With bisect implementation, you leave all that to the algorithm and just parent once.

In the end, I admit that this was a quick first stab at the problem and might not be the greatest code or there may be a more beautiful, idiomatic simpler pythonic way of doing this through the use of dictionaries or some other standard container.



On Fri, Sep 16, 2016 at 10:04 PM, Marcus Ottosson <konstr...@gmail.com> wrote:
> but then you should do this lookup only once for each node and not iterate through each key and then deep inside it until some condition is reached. To me, that is a bit complex.

Ah, yes that is true. I did not think of that. Thanks for pointing that out.

As someone who isn't terribly familiar with bisect, how does bisect achieve this if not by traversing each node in turn and returning the first found, like how the dict is being used currently?
On 16 September 2016 at 15:01, Alok Gandhi <alok.ga...@gmail.com> wrote:
Hi Marcus,

My objective was simple, parenting is the main focus and it should be done  once and only once for each node in the hierarchy. To achieve this, during each iteration the node should have knowledge about his parent just by knowing its position (indent).

I did not want complex processing of saving states and whole trees and then lookup up and down. The node should have a place (the tuple list) to look for its parent. It simply asks this question - I have this position, who is my parent. This is typically looking for an insertion point in an array and bisect was a perfect candidate for these requirements.

After finding the parent, the node attaches itself to the list replacing the current node at that position so that preceding nodes can find it as a parent when required.

Using a dict is a better option just for the reason of O(1) lookup times, but then you should do this lookup only once for each node and not iterate through each key and then deep inside it until some condition is reached. To me, that is a bit complex.

On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson <konstr...@gmail.com> wrote:
Ok, Alok, I had a closer look at your example and the bisect module in Python.

In my example, a dict replaces bisect. The dict is limited, in that once a parent at the same level as an above parent appears, the above parent vanishes from consideration. But in this case, maybe that works to our advantage? Could you tell me about your motivation for using bisect?

--
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_maya+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/d86fb040-1d59-492d-8b7c-50dc5cf67d96%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 python_inside_maya+unsubscribe@googlegroups.com.



--
Marcus Ottosson
konstr...@gmail.com

--
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_maya+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Ian Jones

unread,
Sep 16, 2016, 12:35:37 PM9/16/16
to python_in...@googlegroups.com
It can be achieved without iteration if you solve the original problem in another way.

If the problem originally is:

I’m putting together a minor helper function for establishing a transform hierarchy within Maya but am not yet satisfied with the implementation. 

Then I might suggest something like this:

  1. import maya.cmds
  2.  
  3. class Node(object):
  4.     def __init__(self,name,children=None,type='transform'):
  5.         self.name = name
  6.         self.type = type
  7.         self.children = children if children is not None else list()
  8.        
  9.     def create(self):
  10.         node = None
  11.         if maya.cmds.objExists(self.name):
  12.             node = self.name
  13.         else:
  14.             node = maya.cmds.createNode(self.type,name=self.name,skipSelect=True)
  15.            
  16.         for child in self.children:
  17.             maya.cmds.parent(child.create(),node)
  18.        
  19.         return node
  20.        
  21.  
  22. hierarchy = Node('rig',
  23.                  [
  24.                      Node('implementation',
  25.                           [
  26.                               Node('geoemtry'),
  27.                               Node('skeleton')
  28.                               ]),
  29.                      Node('interface',
  30.                           [
  31.                               Node('controls'),
  32.                               Node('preview'),
  33.                               ]),
  34.                  ])
  35. hierarchy.create()

Where you define and record the hierarchy as you go then simply create it on demand. It may feel like the hierarchy definition (line 22-34) is more complex than your basic string but it will be much easier to maintain if you wanted to add additional information like nodeType or custom attributes/markup. Readability is a perfectly valid goal to seek but I find maintainability is often overlooked. In my experience code seems to last much longer than the original author anticipated. In driving to a solution avoiding the additional markup (as in my solution or in json/xml) you've likely put yourself (and too often your team after you've left) in a place where you'll need to rewrite the function for future feature requests.

As for the performance side of the world I suggest using the profiler (import cProfile;cProfile.run(str) as it's simplest) to understand what your code is doing. Unless you're building a very large hierarchy I doubt you'll noticed the difference in performance being dict/bisect. In the effort to avoid the scan Alok's solution introduced a number of other performance penalties (mostly due to pymel, but also due to searching the scene twice). 

Marcus:
 - 49 function calls in 0.005 seconds
Mine:
 - 29 function calls (23 primitive calls) in 0.003 seconds
Alok:
- 3246 function calls (3239 primitive calls) in 0.011 seconds

Ian



 

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.



--

--
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.



--
Marcus Ottosson
konstr...@gmail.com

--
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.



--

--
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/CAPaTLMTxrmjYe%2B%3Dt1f8C6AJO3KziSscq%3DYF4eMGQrwv%3DTy13AA%40mail.gmail.com.

Marcus Ottosson

unread,
Sep 16, 2016, 12:57:11 PM9/16/16
to python_in...@googlegroups.com
Thanks Ian!

Some notes.

- The implementation is up for grabs, but I'd like to keep the interface of the function; that is, passing a single string with indentation for hierarchy.
- Performance is not important here, because (1) the function is only being used in example code, where the call itself should fall into the background and (2) creating a hierarchy can safely take a few hundred milliseconds if it means more readable code.

Alok Gandhi

unread,
Sep 16, 2016, 12:57:29 PM9/16/16
to python_in...@googlegroups.com
Hi Ian,

Although your approach is so valid, I was working under the following constraints, most of which were assumptions:
1.  Marcus originally presented a single function with a need to reimplement it to achieve a few specific goals as he mentioned.
2. I wanted to keep the signature of the function as is.

If I were to freely implement this having more freedom and knowledge about Marcus's intended use, I would have thought of many other ways to achieve this, including something like yours.

As for the performance, I think you're right about my use of pymel. But other than that,

> but also due to searching the scene twice
Can you elaborate on that? As far as I know I am not searching the scene twice, but maybe you saw something that I missed.

And only very minor,
  1. self.children = children if children is not None else list()

could be
  1. self.children = children or list()

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.



--

--
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_maya+unsub...@googlegroups.com.



--
Marcus Ottosson
konstr...@gmail.com

--
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_maya+unsub...@googlegroups.com.



--

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAL6_5Q-cd7np8pv74FZ%3DK4f_bKZrBpq%3DTis6UEMbsSRxv7AxGw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

Alok Gandhi

unread,
Sep 16, 2016, 1:27:46 PM9/16/16
to python_in...@googlegroups.com
Ah ok, just saw Marcus's answer, so most of my assumptions were correct. I would still say, there are many ways to achieve the same thing in programming. With the kind of flexibility, that python provides, the 'many ways' becomes 'so many ways'.

Coming back to some of the points that Ian raised:
    > Readability is a perfectly valid goal to seek but I find maintainability is often overlooked.

IMHO more readable code is more maintainable. Readability goes hand in hand with maintainability. In fact, I very much agree that code lasts longer than an author and if you write readable code it will be easier to read and understand for the people after you are gone and are not available to explain why you did what. If by maintainability you meant actually extensibility, then it is a completely different aspect.

> In driving to a solution avoiding the additional markup (as in my solution or in json/XML) you've likely put yourself (and too often your team after you've left) in a place where you'll need to rewrite the function for future feature requests.

If you read my previous posts in this threads, you will see that I clearly mentioned that getting input is an administrative logic. In fact, I provisioned for it and alluded to Marcus about it. Here's what I wrote:
  • Right in the beginning, we parse the string in a single line, keeping the administrative logic out from the rest of our business code. You can easily replace this single line with whatever parser you want.
This means that the code that is responsible for creating nodes should not worry itself with how it is getting the data in, JSON or YAML. And the parser, whichever it is, should not worry about what is going to happen to data it outputs. any good architecture should take care of this point. Making components decoupled and flexible. Good architecture does not only apply to huge libraries or big project, it should be given thought to every single small quantum of code, a function and even inside parts of a function. I did not avoid the input data structure, I simply did not work on that part as was not required my Marcus originally. Even then, I separated the code so that in my implementation, nowhere it does rely on whether I choose JSON or YAML or some other markup. If ten years later, somebody wants to use my implementation, with JSON the only change it would require is to change the first line of my code.



--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

Justin Israel

unread,
Sep 16, 2016, 6:16:17 PM9/16/16
to python_in...@googlegroups.com
On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <alok.ga...@gmail.com> wrote:

Coming back to some of the points that Ian raised:
    > Readability is a perfectly valid goal to seek but I find maintainability is often overlooked.

IMHO more readable code is more maintainable. Readability goes hand in hand with maintainability. In fact, I very much agree that code lasts longer than an author and if you write readable code it will be easier to read and understand for the people after you are gone and are not available to explain why you did what. If by maintainability you meant actually extensibility, then it is a completely different aspect.

As an aside, I just recently went to a convention, and in one of the talks the speaker opened with his list of priorities for designing software: 

1. Integrity - The software should operate in a predictable manner, respond appropriately to exceptional conditions, and clean up nicely during a termination

2. Readability - The intent of the code should be clear

3. Simplicity (has to be justified to be more important than #2)

4. Performance


He basically yelled at us for 10 minutes about the importance of the first two, and said only when you can prove to me that everything else is addressed, that you should then look at performance. It was a pretty good talk.  


> In driving to a solution avoiding the additional markup (as in my solution or in json/XML) you've likely put yourself (and too often your team after you've left) in a place where you'll need to rewrite the function for future feature requests.

If you read my previous posts in this threads, you will see that I clearly mentioned that getting input is an administrative logic. In fact, I provisioned for it and alluded to Marcus about it. Here's what I wrote:
  • Right in the beginning, we parse the string in a single line, keeping the administrative logic out from the rest of our business code. You can easily replace this single line with whatever parser you want.
This means that the code that is responsible for creating nodes should not worry itself with how it is getting the data in, JSON or YAML. And the parser, whichever it is, should not worry about what is going to happen to data it outputs. any good architecture should take care of this point. Making components decoupled and flexible. Good architecture does not only apply to huge libraries or big project, it should be given thought to every single small quantum of code, a function and even inside parts of a function. I did not avoid the input data structure, I simply did not work on that part as was not required my Marcus originally. Even then, I separated the code so that in my implementation, nowhere it does rely on whether I choose JSON or YAML or some other markup. If ten years later, somebody wants to use my implementation, with JSON the only change it would require is to change the first line of my code.


On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <konstr...@gmail.com> wrote:
Thanks Ian!

Some notes.

- The implementation is up for grabs, but I'd like to keep the interface of the function; that is, passing a single string with indentation for hierarchy.
- Performance is not important here, because (1) the function is only being used in example code, where the call itself should fall into the background and (2) creating a hierarchy can safely take a few hundred milliseconds if it means more readable code.

--
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.



--

--
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/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com.

yury nedelin

unread,
Sep 16, 2016, 9:09:29 PM9/16/16
to python_in...@googlegroups.com

Is performance something you are concerned with for this process?
Yury

On Sep 16, 2016 6:16 PM, "Justin Israel" <justin...@gmail.com> wrote:
On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <alok.ga...@gmail.com> wrote:

Coming back to some of the points that Ian raised:
    > Readability is a perfectly valid goal to seek but I find maintainability is often overlooked.

IMHO more readable code is more maintainable. Readability goes hand in hand with maintainability. In fact, I very much agree that code lasts longer than an author and if you write readable code it will be easier to read and understand for the people after you are gone and are not available to explain why you did what. If by maintainability you meant actually extensibility, then it is a completely different aspect.

As an aside, I just recently went to a convention, and in one of the talks the speaker opened with his list of priorities for designing software: 

1. Integrity - The software should operate in a predictable manner, respond appropriately to exceptional conditions, and clean up nicely during a termination

2. Readability - The intent of the code should be clear

3. Simplicity (has to be justified to be more important than #2)

4. Performance


He basically yelled at us for 10 minutes about the importance of the first two, and said only when you can prove to me that everything else is addressed, that you should then look at performance. It was a pretty good talk.  


> In driving to a solution avoiding the additional markup (as in my solution or in json/XML) you've likely put yourself (and too often your team after you've left) in a place where you'll need to rewrite the function for future feature requests.

If you read my previous posts in this threads, you will see that I clearly mentioned that getting input is an administrative logic. In fact, I provisioned for it and alluded to Marcus about it. Here's what I wrote:
  • Right in the beginning, we parse the string in a single line, keeping the administrative logic out from the rest of our business code. You can easily replace this single line with whatever parser you want.
This means that the code that is responsible for creating nodes should not worry itself with how it is getting the data in, JSON or YAML. And the parser, whichever it is, should not worry about what is going to happen to data it outputs. any good architecture should take care of this point. Making components decoupled and flexible. Good architecture does not only apply to huge libraries or big project, it should be given thought to every single small quantum of code, a function and even inside parts of a function. I did not avoid the input data structure, I simply did not work on that part as was not required my Marcus originally. Even then, I separated the code so that in my implementation, nowhere it does rely on whether I choose JSON or YAML or some other markup. If ten years later, somebody wants to use my implementation, with JSON the only change it would require is to change the first line of my code.


On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <konstr...@gmail.com> wrote:
Thanks Ian!

Some notes.

- The implementation is up for grabs, but I'd like to keep the interface of the function; that is, passing a single string with indentation for hierarchy.
- Performance is not important here, because (1) the function is only being used in example code, where the call itself should fall into the background and (2) creating a hierarchy can safely take a few hundred milliseconds if it means more readable code.

--
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_maya+unsub...@googlegroups.com.
--

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Sxx%2B2319C1Mv4omtaiEvjppJPrFjVYtgmYxSJvs74AQ%40mail.gmail.com.

Justin Israel

unread,
Sep 16, 2016, 9:15:45 PM9/16/16
to python_in...@googlegroups.com


On Sat, 17 Sep 2016, 1:09 PM yury nedelin <yned...@gmail.com> wrote:

Is performance something you are concerned with for this process?
Yury

Marcus had said it was not a concern. I was just sharing some interesting info on the topic of readability and maintainability

On Sep 16, 2016 6:16 PM, "Justin Israel" <justin...@gmail.com> wrote:
On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <alok.ga...@gmail.com> wrote:

Coming back to some of the points that Ian raised:
    > Readability is a perfectly valid goal to seek but I find maintainability is often overlooked.

IMHO more readable code is more maintainable. Readability goes hand in hand with maintainability. In fact, I very much agree that code lasts longer than an author and if you write readable code it will be easier to read and understand for the people after you are gone and are not available to explain why you did what. If by maintainability you meant actually extensibility, then it is a completely different aspect.

As an aside, I just recently went to a convention, and in one of the talks the speaker opened with his list of priorities for designing software: 

1. Integrity - The software should operate in a predictable manner, respond appropriately to exceptional conditions, and clean up nicely during a termination

2. Readability - The intent of the code should be clear

3. Simplicity (has to be justified to be more important than #2)

4. Performance


He basically yelled at us for 10 minutes about the importance of the first two, and said only when you can prove to me that everything else is addressed, that you should then look at performance. It was a pretty good talk.  


> In driving to a solution avoiding the additional markup (as in my solution or in json/XML) you've likely put yourself (and too often your team after you've left) in a place where you'll need to rewrite the function for future feature requests.

If you read my previous posts in this threads, you will see that I clearly mentioned that getting input is an administrative logic. In fact, I provisioned for it and alluded to Marcus about it. Here's what I wrote:
  • Right in the beginning, we parse the string in a single line, keeping the administrative logic out from the rest of our business code. You can easily replace this single line with whatever parser you want.
This means that the code that is responsible for creating nodes should not worry itself with how it is getting the data in, JSON or YAML. And the parser, whichever it is, should not worry about what is going to happen to data it outputs. any good architecture should take care of this point. Making components decoupled and flexible. Good architecture does not only apply to huge libraries or big project, it should be given thought to every single small quantum of code, a function and even inside parts of a function. I did not avoid the input data structure, I simply did not work on that part as was not required my Marcus originally. Even then, I separated the code so that in my implementation, nowhere it does rely on whether I choose JSON or YAML or some other markup. If ten years later, somebody wants to use my implementation, with JSON the only change it would require is to change the first line of my code.


On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <konstr...@gmail.com> wrote:
Thanks Ian!

Some notes.

- The implementation is up for grabs, but I'd like to keep the interface of the function; that is, passing a single string with indentation for hierarchy.
- Performance is not important here, because (1) the function is only being used in example code, where the call itself should fall into the background and (2) creating a hierarchy can safely take a few hundred milliseconds if it means more readable code.

--
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.
--

--
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.

--
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.
--
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/CACqGSch6_LnZ%3DXajnQ%3DAZX%2Br2Fwy99rW8WjM4kdUCmKMUpb7jA%40mail.gmail.com.

Alok Gandhi

unread,
Sep 17, 2016, 1:34:03 AM9/17/16
to python_in...@googlegroups.com
@Justin: I agree with readability trumping performance, and almost at all times, I follow almost the same tenets. However, in our trade, performance is ever more critical and is becoming important every single day. The entertainment industry is one of the major stakeholders when it comes to demand for processing power. We need that water to look real, 10 million polygon processing, we need that. And on top of that, we work on deadlines, sometimes unreal. When there is a pressing need to process huge amounts of data so that the shot can be approved, we have to do that. And it is at such moments, readability might take a back seat. This by no means is a justification for ignoring readability but rather the state of affairs. There is sometimes a tradeoff involved, sometimes not. You can get the best of both the worlds if you have enough time on your hand.

It is good that we have a growing and healthy open source community, with studios investing in making amazing open source projects - OpenVDB exr, Alembic, USD etc. to name a few. With neatly written API to handle low-level high-processing procedures, all abstracted for the benefit of writing clean yet power packed code.

That's my two cents.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
--

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0oCXTvXzUC%2BBdkfotstBL%2BJ%3D32tmhXS3rETQxKQ7Q2HQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

Justin Israel

unread,
Sep 17, 2016, 1:48:01 AM9/17/16
to python_in...@googlegroups.com
On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi <alok.ga...@gmail.com> wrote:
@Justin: I agree with readability trumping performance, and almost at all times, I follow almost the same tenets. However, in our trade, performance is ever more critical and is becoming important every single day. The entertainment industry is one of the major stakeholders when it comes to demand for processing power. We need that water to look real, 10 million polygon processing, we need that. And on top of that, we work on deadlines, sometimes unreal. When there is a pressing need to process huge amounts of data so that the shot can be approved, we have to do that. And it is at such moments, readability might take a back seat. This by no means is a justification for ignoring readability but rather the state of affairs. There is sometimes a tradeoff involved, sometimes not. You can get the best of both the worlds if you have enough time on your hand.

I appreciate this need. Ultimately we have to deliver shots and meet deadlines. Ultimately we are in the business of making Movies/Television/Games/<entertainment>, and not necessarily software. 

But really, it doesn't change the point of the advise from that conference speaker. Even if performance ends up becoming the primary focus, then naturally the other points become secondary. And you have to weigh those decisions, right? Do we need this solution beyond this shot? This show? Who gets to maintain it? How easy it is to continue to be adapted to the next challenge.

Also I would like to throw my 2 cents in as someone that develops not as one that writes scripts and tools on a per-show basis to get shots finaled, but as one that works on longer term projects to serve the ongoing pipeline. The advise from that conference might be more applicable to situations like that, where a shot-delivery time frame is not the case. It really just depends on whether your deliverable is a shot, or software. 
 
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
--

--
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.

--
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.

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

--
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.
--
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/CAPaTLMSybL5Gp6zch%3DzxgqxMuxGkRHDBVMDWjG0kRg%2BfTJM7DA%40mail.gmail.com.

Alok Gandhi

unread,
Sep 17, 2016, 2:12:14 AM9/17/16
to python_in...@googlegroups.com
Also I would like to throw my 2 cents in as someone that develops not as one that writes scripts and tools on a per-show basis to get shots finaled, but as one that works on longer term projects to serve the ongoing pipeline. The advise from that conference might be more applicable to situations like that, where a shot-delivery time frame is not the case. It really just depends on whether your deliverable is a shot, or software. 

I agree, I am also employed as a Pipeline Engineer and do not have the pressing need to script  for a single shot but rather develop Pipeline Tools and APIs that are consumed by various departments. I can totally understand where you are coming from and it makes complete sense. I started out as an artist (animator, rigger, and generalist) and then a TD and gradually segway into Pipeline. During this journey, I clearly saw my development focus shift from 'just make it work' to 'make it beautiful and readable'.

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
--

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1WcHaU9YQdsan5rJA30tnVxEjMo6BKKb4sc9Rbm_ACBA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--

Justin Israel

unread,
Sep 17, 2016, 2:18:22 AM9/17/16
to python_in...@googlegroups.com


On Sat, 17 Sep 2016, 6:12 PM Alok Gandhi <alok.ga...@gmail.com> wrote:
Also I would like to throw my 2 cents in as someone that develops not as one that writes scripts and tools on a per-show basis to get shots finaled, but as one that works on longer term projects to serve the ongoing pipeline. The advise from that conference might be more applicable to situations like that, where a shot-delivery time frame is not the case. It really just depends on whether your deliverable is a shot, or software. 

I agree, I am also employed as a Pipeline Engineer and do not have the pressing need to script  for a single shot but rather develop Pipeline Tools and APIs that are consumed by various departments. I can totally understand where you are coming from and it makes complete sense. I started out as an artist (animator, rigger, and generalist) and then a TD and gradually segway into Pipeline. During this journey, I clearly saw my development focus shift from 'just make it work' to 'make it beautiful and readable'.

100% agree!

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
--

--
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.

--
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.

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

--
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.

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

--
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.
--
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/CAPaTLMSF%3Defsqh2CFxPztR_Drb4jwASeJHgwAa1hDk2sRjEwdg%40mail.gmail.com.

Geordie Martinez

unread,
Sep 19, 2016, 2:21:49 AM9/19/16
to python_inside_maya

Okay. I know this has probably already been figured out, but I can’t help myself with puzzles. Marcus I think you were on to the right idea but just needed to use an OrderedDict with enumerate. here is my stab at it:

import maya.cmds as mc
from collections import OrderedDict
def hierarchy_from_string(hierarchy):
    stack = OrderedDict()
    
for line in hierarchy.split("\n"
):
        if not line:
            continue
        stack[line.strip()]= len(line) -len(line.strip())
    node_stack = stack.keys()
    for num,(k,v) in enumerate(stack.iteritems()):
        tfm = mc.group(n=k,em=True)
        if num:
            par_stack = node_stack[:num]
            par_stack.reverse()
            for pp in par_stack:
                if stack[pp] < v:
                    mc.parent(tfm,pp)
                    break

    return stack

hStr = """\
rig
    implementation
        geometry
        skeleton
    interface
        controls
        preview
"""

hierarchy_from_string(hStr)

this will only work in this current example if there aren’t any duplicate names.

​

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
--

--
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_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.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 python_inside_maya+unsub...@googlegroups.com.

--
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_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2KPoE5g8DxsTeONLAKKbyqhJKkhM%2B6ZKJDaX0gsasr_g%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages