Just to go a little further deep in the OT zone, I found this lecture very interesting, as it explains how the dictionnaries work behind the scenes: http://pyvideo.org/video/276/the-mighty-dictionary-55
2014-12-07 10:47 GMT+01:00 Christopher Crouzet < [email protected]>: > Interesting! I would never have think that hash values would differ for a > same object, how lame indeed. > I wasn't even aware of the existance of the class `MObjectHandle`. It > seems to be as much of a joke as the `MScriptUtil` class is. > > After all I'm not even surprised anymore and that's why I originally > started to develop a monkey patching library similar to what the ` > banana.maya` one is today. > > To make good use of your findings, I've made changes to the `banana.maya` > library to cover this case by monkey patching the original `__hash__()` > method. In normal cases it's highly discouraged to override existing > methods through monkey patching but I don't see how it could do any harm > here—how could one possibly rely on its original behavior? And at the end > of the day, no one's using my library so I'm not risking to break things! :) > > > https://github.com/christophercrouzet/banana.maya/commit/45e90866933ec29512010f5f52705b16cbf61099 > > This indeed seems to fix the initial issue with the set. > > > On 5 December 2014 at 03:41, Justin Israel <[email protected]> wrote: > >> That is an interesting point you have discovered. A set (and a dict) rely >> on the hash of the object, whereas doing an "in" membership test in a list >> rely on the equality of the two objects. >> >> Given two MObject instances that point to the same Maya object: >> >> a == b >> # True >> >> hash(a) == hash(b) >> # False >> >> This means that the MObject only defines the equality operators, but >> their hash returns different values, making them useless for sets. It is >> kind of lame that the MObjects are that way. It would work fine if you were >> dealing with containers all pointing as the same MObject instances. But if >> you have containers that have MObject results from different calls, then it >> won't work. The closest thing they have seems to be this: >> >> om.MObjectHandle(a).hashCode() == om.MObjectHandle(b).hashCode() >> # True >> >> ... where they make you go and retrieve the hash code for your object, as >> opposed to just making SWIG do it for you in the __hash__() method of the >> python wrapper. >> >> >> On Wed Dec 03 2014 at 16:59:34 Christopher Crouzet < >> [email protected]> wrote: >> >>> Aaah, I understand you now about the list(iterator) vs set(iterator) and >>> you're right, I could definitely have used a set here from a semantic point >>> of view. >>> >>> >>> While we're still in the OT for the sake of the informative archive, >>> I've been intrigued and, as a set newbie that I am, I've just discovered >>> the existance of the operator “-” allowing to return the difference between >>> two sets. So I thought “cool” and I tried to implement the method entirely >>> with sets for the fun of it, even though I knew I wouldn't like the final >>> conversion to a list: >>> >>> def bnn_importFile(cls, fileName, type='', preserveReferences=False, >>> nameSpace='', ignoreVersion=False): >>> if not type: >>> type = None >>> >>> if not nameSpace: >>> nameSpace = None >>> >>> topLevelDagPaths = set(OpenMaya.bnn_MItDagHierarchy()) >>> OpenMaya.MFileIO.importFile(fileName, type, preserveReferences, >>> nameSpace, ignoreVersion) >>> return list(set(OpenMaya.bnn_MItDagHierarchy()) - >>> topLevelDagPaths) >>> >>> >>> The operator “-” doesn't seem to do its job here. I don't want to spend >>> time investigating the issue but I quickly checked if the required ` >>> __hash__()` and `__eq__()` methods for such an operation to work were >>> well defined for OpenMaya.MDagPath objects, and it seems to be the case. >>> That's a bit of a mystery. >>> >>> >>> On 3 December 2014 at 04:16, Justin Israel <[email protected]> >>> wrote: >>> >>>> @ Christopher, I completely agree that constructing temporary sets from >>>> lists adds the overhead. I was only going off your own code example where >>>> you already convert your dag iterator into a list: list(iterator), vs >>>> doing set(iterator). Sets do have a slightly higher cost for construction. >>>> But again, following my "first thought" mentality, I would have probably >>>> figured that the loop and membership test is the focus and not the >>>> construction. Again, I also completely agree that readability counts. But >>>> if just doing s/list/set/ improves time complexity without sacrificing >>>> readability, I tend to commit that to my "first thought" muscle memory. >>>> >>>> @ Joe, ya that's actually what I like about allowing threads to >>>> slightly go off-topic on this list. It tends to bring out pretty useful >>>> discussions. Maybe other lists are pretty adamant about keeping each thread >>>> on topic, and generally it would be a good idea. But at least this side >>>> discussion wasn't completely off topic, as it was discussing extra code >>>> that was presented as an example for the original topic. >>>> >>>> It all adds up anyways to a pretty informative archive. >>>> >>>> >>>> On Wed Dec 03 2014 at 05:52:50 Joe Weidenbach <[email protected]> >>>> wrote: >>>> >>>>> Not to perpetuate a long discussion, but I personally find lots of >>>>> benefits in discussing multiple ways of achieving things on a list such as >>>>> this. I haven't dealt with file imports from a script in a while myself, >>>>> but the thing I picked up from this was the assemblies trick. In my >>>>> younger, more naive days, I wrote an importer and then proceeded to check >>>>> each node and see if it was a root node or not, looping over it as I went. >>>>> I found the returnNewNodes flag in the documentation for file, and used >>>>> that list, iterating manually over it with listRelatives. The assemblies >>>>> thing would have saved me a lot of loops there, and been much clearer to >>>>> read. It's all about building the toolbelt! >>>>> >>>>> >>>>> On 12/2/2014 4:26 AM, Christopher Crouzet wrote: >>>>> >>>>> @Marucs: WHAT ARE YOU TALKING ABOUT!? I AM ALREADY RELAXED!!!$#^(*&@ >>>>> >>>>> @Justin: my previous comments were only aimed towards avoiding >>>>> premature optimization but now that's another topic. Optimizations aside, >>>>> I >>>>> share your point of view regarding your “first thought”. The idea is to >>>>> code using the tools that express the best the intentions of the >>>>> developer. >>>>> If the idea is to have an unique set of elements, then a set is a good >>>>> choice. >>>>> >>>>> Still, I'm subjectively happy with my choice of using a >>>>> comprehensive list in the context of the `bnn_importFile()` method because >>>>> it was the simplest to use. I'm a bit rusty with Python right now, so >>>>> maybe >>>>> I'm wrong, but I believe that if I've had to implement that method using >>>>> sets, then I would have had to deal with needless conversions from/to >>>>> lists, which would have made the code less readable without any real >>>>> improvement on my intentions (I believe it's quite obvious already, and >>>>> Marcus proved it)—I'm not even talking here of the additional allocations >>>>> that those conversions would have probably caused on the heap, he he he! >>>>> >>>>> Btw, O(1) does provide better performances than O(n) when processing >>>>> but that would be forgetting the initialization-related costs. When the >>>>> costs of memory allocation due to a more complex data structure are >>>>> significant in comparison to the costs of the operations to process, then >>>>> the O(1) algorithm might lose versus the O(n) one in order of magnitudes. >>>>> If I remember well, that's what the C++ paper of vectors vs sets is >>>>> talking >>>>> about. That's also why most of the time there is no universal trick to >>>>> increase performances and that benchmarking each snippet of code is the >>>>> only way to go when required, and hence why any optimization intuition >>>>> should be dismissed to focus solely on the code semantics. >>>>> >>>>> That being said... optimizations look fun! Can't wait to learn how >>>>> to dig into assembly code :) >>>>> >>>>> >>>>> On 2 December 2014 at 17:29, Justin Israel <[email protected]> >>>>> wrote: >>>>> >>>>>> @Marcus, sorry if my suggestion was vague. My intention was that the >>>>>> list would be that returned from the file import call, when using the >>>>>> "return new nodes" flag. One could take that list and query for the >>>>>> assemblies. >>>>>> >>>>>> @Christopher, while I don't want to further propagate the off-topic >>>>>> discussion, I figured since we are already there, I might throw in my >>>>>> 2cents. I actually see valid points in both your comments as well as >>>>>> Marcus. I definitely agree that premature optimisation is the root of all >>>>>> evil. But what about cases where a certain idiom over another could >>>>>> yield a >>>>>> better possible outcome vs no change at all, simply by it becoming muscle >>>>>> memory? The way I see it, if you aren't expending any extra time trying >>>>>> to >>>>>> optimise a piece of code, and your first thought goes to "membership test >>>>>> in a loop... I'll use a set", did we lose anything by that? In this >>>>>> particular case, maybe using a set yields no quantifiable gain, but does >>>>>> the practice in doing so yield anything over time? Then again, in your >>>>>> defence you are correct that you did not ask for any help and your code >>>>>> was >>>>>> not meant to be the subject of evaluation. But either way, it was code >>>>>> provided, and we tend to spawn conversation on this list at random >>>>>> points. >>>>>> >>>>>> Again, I am just throwing in my thoughts on both sides. My own muscle >>>>>> memory would have made me write a set when looping and testing >>>>>> membership, >>>>>> at no extra "pre-optimization costs" to my development process. I just >>>>>> figure O(1) beats O(n) and if I am wrong, then it is still O(n). But then >>>>>> again no one was asking for opinions :-) >>>>>> >>>>>> >>>>>> On Tue, 2 Dec 2014 11:08 PM Christopher Crouzet < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I provided my suggestion because I knew that it would meet the >>>>>>> requirements of the question. Why would I need to describe its code? >>>>>>> >>>>>>> I'm not offended, it's just annoying to be linked to some >>>>>>> StackOverflow bullshit like if the answer there was some kind of holy >>>>>>> graal >>>>>>> accurately providing a solution for all the problems in the universe. >>>>>>> Even >>>>>>> though the author of the answer rightfully says that “it depends”, and >>>>>>> emphasizes on the need to time it, he still writes as a fact that sets >>>>>>> are >>>>>>> significally faster when checking for uniqueness—thus without any sort >>>>>>> of >>>>>>> proof. In which case is he right or wrong? Maybe it becomes true only >>>>>>> when >>>>>>> using more than 100,000+ elements? Would the results still be the same >>>>>>> for >>>>>>> large elements, or heterogeneous elements? I'd expect from you to be >>>>>>> more >>>>>>> critic towards this kind of things. >>>>>>> >>>>>>> I'd also expect from you to not give such advices that you don't >>>>>>> know true for sure, especially since I haven't asked any help on the >>>>>>> subject. If I was a newbie, I would believe you as well as that author >>>>>>> on >>>>>>> SO, and maybe I would go on rewriting all my codebase to use sets for >>>>>>> such >>>>>>> cases and tell all my friends to do the same, until I'd realize 2 years >>>>>>> later how wrong it all is. All this when *we shouldn't even have >>>>>>> been talking about this matter* for such a non-critical code that >>>>>>> is meant to run once and where *readability prevails*. >>>>>>> >>>>>>> It's of course a stupid example but—and you can find some more >>>>>>> literature on the subject—all I'm trying to say here is to be careful on >>>>>>> what you say as it can/will influence others and might perpetuate bad >>>>>>> coding practices. >>>>>>> >>>>>>> Enough OT. >>>>>>> >>>>>>> >>>>>>> On 2 December 2014 at 16:27, Marcus Ottosson <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Christopher, I’m sorry I didn’t read too carefully through your >>>>>>>> code, but you didn’t really provide much information to along with your >>>>>>>> suggestion to use your library for the task in the OP. >>>>>>>> >>>>>>>> and since you seem to enjoy reading development practices online >>>>>>>> >>>>>>>> I’m sensing I may have offended you, sorry about that. >>>>>>>> >>>>>>>> the number of items being checked for uniqueness within the list >>>>>>>> comprehension is most likely to be very (very) small >>>>>>>> >>>>>>>> My suggestion to use sets here was in regards to comparing all >>>>>>>> nodes contained within a file. Files may contain quite a few nodes, >>>>>>>> even in >>>>>>>> the hundreds of thousands, and in these cases I believe sets produce a >>>>>>>> noticeable difference. >>>>>>>> >>>>>>>> >>>>>>>> On 2 December 2014 at 09:08, Christopher Crouzet < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> I believe you're wrong on both points. >>>>>>>>> >>>>>>>>> Firstly, the constructor of the iterator `bnn_MItDagHiearchy >>>>>>>>> <https://github.com/christophercrouzet/banana.maya/blob/master/banana/maya/extensions/OpenMaya/iterators.py#L214>` >>>>>>>>> has a default argument `recursive=false`, meaning that only the top >>>>>>>>> (assembly) DAG nodes will be returned, as expected by the >>>>>>>>> `bnn_importFile()` method. >>>>>>>>> >>>>>>>>> Secondly, and since you seem to enjoy reading development >>>>>>>>> practices online, you must know that you shouldn't talk about >>>>>>>>> premature >>>>>>>>> optimizations when there's no actual performance issues. Especially >>>>>>>>> in this >>>>>>>>> case where: >>>>>>>>> - the method `bnn_importFile()` most likely won't be used in a >>>>>>>>> tight loop. And even if it does, the performance limitations would >>>>>>>>> come >>>>>>>>> from the actual import of the file incurred by Maya rather than from >>>>>>>>> something as insignificant as choosing between list-comprehension or >>>>>>>>> sets. >>>>>>>>> - the number of items being checked for uniqueness within the list >>>>>>>>> comprehension is most likely to be very (very) small, and hence there >>>>>>>>> more >>>>>>>>> likely won't be any noticeable difference in performances whatever >>>>>>>>> method >>>>>>>>> is used, even if you decided to generate that list 17458 times in a >>>>>>>>> row. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2 December 2014 at 15:31, Marcus Ottosson < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Also as a variation to what Marcus suggested, instead of >>>>>>>>>> needing to first capture the assemblies in the scene, do the import, >>>>>>>>>> and >>>>>>>>>> compare the new assemblies listing to the old one with a set, you >>>>>>>>>> can just >>>>>>>>>> pass your list of nodes to ls() and have it return just the >>>>>>>>>> assemblies. >>>>>>>>>> >>>>>>>>>> The question is, which list do you pass? The reason for doing a >>>>>>>>>> before and after is getting the difference in order to figure out >>>>>>>>>> which >>>>>>>>>> nodes were imported, and which were already there. >>>>>>>>>> >>>>>>>>>> Using the Maya Python API: >>>>>>>>>> >>>>>>>>>> topLevelDagPaths = list(OpenMaya.bnn_MItDagHierarchy()) >>>>>>>>>> OpenMaya.MFileIO.importFile(fileName, type, preserveReferences, >>>>>>>>>> nameSpace, ignoreVersion)return [dagPath >>>>>>>>>> for dagPath in OpenMaya.bnn_MItDagHierarchy() >>>>>>>>>> if not dagPath in topLevelDagPaths] >>>>>>>>>> >>>>>>>>>> Which seems to iterate using OpenMaya.MItDag(OpenMaya. >>>>>>>>>> MItDag.kBreadthFirst) >>>>>>>>>> >>>>>>>>>> It looks like this will return *all* imported nodes, and not >>>>>>>>>> just the assembilies. In addition, finding differences via >>>>>>>>>> list-comprehension is about 100x slower than using sets. >>>>>>>>>> >>>>>>>>>> - http://stackoverflow.com/questions/2831212/python-sets- >>>>>>>>>> vs-lists >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1 December 2014 at 23:42, Christopher Crouzet < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Using the Maya Python API: https://github.com/ >>>>>>>>>>> christophercrouzet/banana.maya/blob/master/banana/maya/ >>>>>>>>>>> extensions/OpenMaya/MFileIO.py#L19 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2 December 2014 at 05:54, Justin Israel < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Also as a variation to what Marcus suggested, instead of >>>>>>>>>>>> needing to first capture the assemblies in the scene, do the >>>>>>>>>>>> import, and >>>>>>>>>>>> compare the new assemblies listing to the old one with a set, you >>>>>>>>>>>> can just >>>>>>>>>>>> pass your list of nodes to ls() and have it return just the >>>>>>>>>>>> assemblies: >>>>>>>>>>>> >>>>>>>>>>>> cmds.ls(nodes, assemblies=True) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue Dec 02 2014 at 11:05:59 Marcus Ottosson < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> That's a clever approach! >>>>>>>>>>>>> >>>>>>>>>>>>> Along those lines, you could also opt to import files under >>>>>>>>>>>>> a given namespace; all nodes, including non-DAG ones, will end up >>>>>>>>>>>>> within >>>>>>>>>>>>> the namespace. As a side-note, this is probably as close as >>>>>>>>>>>>> you'll get to >>>>>>>>>>>>> the Softimage "Model". >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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+ >>>>>>>>>>>>> [email protected]. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>>>>>>>> CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0 >>>>>>>>>>>>> wA%40mail.gmail.com >>>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOABXtVoG4ruZHg%3DyBMc3oCiRN3mZcoT38J63UcZznj0wA%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 python_inside_maya+ >>>>>>>>>>>> [email protected]. >>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>>>>>>> CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ% >>>>>>>>>>>> 40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3mmgOK4BLFdXZAm_bs7s%2BvfEgyVr-YQkf%2BLPjy%3DM-mYQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Christopher Crouzet >>>>>>>>>>> *http://christophercrouzet.com* <http://christophercrouzet.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+ >>>>>>>>>>> [email protected]. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>>>>>> CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw% >>>>>>>>>>> 40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW501RmgWsAnNCj-CWQF2w3%2Bv1owr9KCAwFmaZDsgChs8Jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Marcus Ottosson* >>>>>>>>>> [email protected] >>>>>>>>>> -- >>>>>>>>>> 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/ >>>>>>>>>> CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ% >>>>>>>>>> 40mail.gmail.com >>>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAhMU30FaYfqQ1QsOj%3DUdUkuwWWHL8COTp8Tk6em3mDVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Christopher Crouzet >>>>>>>>> *http://christophercrouzet.com* <http://christophercrouzet.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 [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>>>> CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA% >>>>>>>>> 40mail.gmail.com >>>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW52KLkM1hMXVqGodK41Yep8gX%3Dd0isoN0r%2BxcQWXSqxLZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Marcus Ottosson* >>>>>>>> [email protected] >>>>>>>> -- >>>>>>>> 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/CAFRtmODS% >>>>>>>> 2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com >>>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODS%2Bj8qweKoSWFTm4Tosbj-MS6SKTZB_ghXU_DPQKS4uQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>>>> >>>>>>>> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Christopher Crouzet >>>>>>> *http://christophercrouzet.com* <http://christophercrouzet.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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>> CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3% >>>>>>> 2BoXg%40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW537NmV-dL147iCU%3DnhOOQ3ZGF1hqPngmC91c8okN3%2BoXg%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/ >>>>>> CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0vFV6CDKofGnNkcwoSY3c4BhRAUakPZy-4rnnBFAKS1w%40mail.gmail.com?utm_medium=email&utm_source=footer>. >>>>>> >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Christopher Crouzet >>>>> *http://christophercrouzet.com* <http://christophercrouzet.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 [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG% >>>>> 2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW53%3Doa9LrxJhcKJZL1zyG%2B08cn1gCUr8SmqZb-a2ZZTVHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> <http://www.avast.com/> >>>>> >>>>> This email is free from viruses and malware because avast! Antivirus >>>>> <http://www.avast.com/> protection is active. >>>>> >>>>> -- >>>>> 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/547DEE42.6080504%40gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/547DEE42.6080504%40gmail.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/CAPGFgA3K3j9OuAxnjNbofHP3aAEN9 >>>> %3DejVYDnfsK2fZoi1whDpg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3K3j9OuAxnjNbofHP3aAEN9%3DejVYDnfsK2fZoi1whDpg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>> >>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Christopher Crouzet >>> *http://christophercrouzet.com* <http://christophercrouzet.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 [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/python_inside_maya/CANuKW53QfHPpzdqsPpMAHPK14GrA8 >>> NnUMf0CrnEL3kPg-MKSJw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW53QfHPpzdqsPpMAHPK14GrA8NnUMf0CrnEL3kPg-MKSJw%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/CAPGFgA1f630D6msNd42eFSEYgVcWFGp-rQQ7fjx9GTCWZLdvng%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1f630D6msNd42eFSEYgVcWFGp-rQQ7fjx9GTCWZLdvng%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Christopher Crouzet > *http://christophercrouzet.com* <http://christophercrouzet.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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CANuKW51fVx%3DvB14EjB3JvK9w%3D6%3DQ1W3HZP7hu4cSji4B-kzK9Q%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CANuKW51fVx%3DvB14EjB3JvK9w%3D6%3DQ1W3HZP7hu4cSji4B-kzK9Q%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/CAD65uq%3DtRTKkco0mV2SDjHuPdsoM5n9foqF_jMTrnHG%3DgghGQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
