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 [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 [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/CAPGFgA0vFV6CDKofGnNkcwoSY3c4B >>>> hRAUakPZy-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. For more options, visit https://groups.google.com/d/optout.
