Rejecting in block an approach by saying it's evil is evil in itself :) I agree though, monkey patching can be evil and dangerous. But it's just a tool, and depending on how it's being used, it can also be harmless and useful. I tried to underline the former the best I could within the article to warn against the risks.
As a side note, I took the precaution to prefix all the methods in the ` banana.maya` library with 'bnn_'. This hopefully highly minimizes the risk of changing the behavior of an existing method. I could also add an option in the Gorilla library to throw an exception whenever a method already exists instead of saving it under another name. On 23 June 2014 19:52, Justin Israel <[email protected]> wrote: > Monkey-patching is a bit of an evil art. Especially when you are modifying > a shared python environment such as Maya. It would have to be done in a way > that doesn't result in crazy breakage for other tools that live in the same > interpreter and expect one type of return value, but get another (Action > At A Distance > <http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)> > ). > > > On Tue, Jun 24, 2014 at 10:57 AM, Christopher Crouzet < > [email protected]> wrote: > >> I'll reply as objectively as possible to your questions but I sincerely >> hope that this thread won't turn into a software war or something. >> >> >> The COM layer allows Softimage's C++ API/object model to be also >> available within all the scripting languages such as Python, JScript, >> VBscript, and even Perl if my memory is correct... but not sure if anyone >> ever used this one to testify that it actually works. This provides a great >> consistency across all the languages and no, it's far from being poor. I've >> started writing my first lines of code with that API and I might be a bit >> biased but I always found it intuitive to use. With a bit more distance, I >> still believe that it's a modern and well designed API. >> >> Now maybe you're referring to the command layer displayed in the script >> editor after each operation done in the interface. This one is just a bunch >> of unordered global functions that beginners can use to create a few >> scripts by copying/pasting the log. That's not designed to code anything >> serious. >> >> >> As for Maya's scripting interface, if you're referring to the commands >> layer (in MEL or Python), then my point of view would be rather the >> opposite. I can't think of how representing nodes with strings can be a >> robust approach (I've had a fun example back then but lost it). And I don't >> understand in what having 409832 flags defined in a same function can be >> helpful. It's just confusing and get worse when you sometimes get some >> functions which features seems to collide such as `getAttr`, ` >> attributeInfo`, and other `attributeQuery`. >> >> I think MEL starts to make sense when we know it's derived from an UNIX >> shell language that has most probably been created with the intention to >> describe ASCII Maya scenes. Like Softimage's command layer, I can't think >> of it being initially created to do some serious development but I guess >> the community just got along with it since it was either that or C++ back >> then. When I see some code written in MEL that retrieve some node >> information by first selecting them, or that hardcore every single name >> without even thinking that there might be more than one node named 'root' >> in the scene, I'm thinking that many don't care much about coding practices >> anyways. >> >> As such, I've never used either MEL or its 1:1 port to Python for >> anything (but when no other choice) and focused only on working solely with >> the API even though I haven't been a big fan of it neither. I can assure >> you that it was indeed a pain and I can understand that most sitck with the >> commands layer. But since I had to learn one or the other, I rather go for >> the way which seemed the most robust to me even though it was more verbose >> and initally required more work on my end. It went better once I >> implemented a few things through monkey patching. >> >> Working with both would also have been a pain, especially from the >> commands layer to the API since a conversion from a string to a MFn object >> would be required every time. The other way around is easier and I actually >> did something (that must be kept secret), which is to override the ` >> __str__` attribute of the `MFnDagNode` class to return the full path >> name of an object. This way I could pass a `MFnDagNode` object directly >> as an argument of a `maya.cmds` function without having to explicitely >> do the conversion. This obviously didn't work for array of objects though. >> >> >> But at the end of the day, it all remain just tools. The most important >> is how they're being used. As such, what precedes is my own way of seeing >> things leading to why I chose to use the API rather than the commands layer >> but I totally respect any other alternatives as soon as it's well coded and >> doesn't break when I use it :) >> >> >> Cheers, >> Christopher. >> >> >> >> On 23 June 2014 16:57, Marcus Ottosson <[email protected]> wrote: >> >>> Well, I’ve just been repeating the documentation really :) >>> >>> I read through some of the code and the post about this on your blog and >>> you’re right, I should’ve investigated better prior to asking, sorry about >>> that. >>> >>> One thing about Banana and monkey-patching the Maya API. I’ve seen a >>> similar reaction to maya.cmds from other persons transitioning from >>> Softimage and I wonder, are you using the API for general scripting such as >>> selecting, and iterating over scene items, or reading from the channelBox >>> etc.? I’ve been writing tools for both Maya and Softimage for quite a few >>> years now and have honestly never found any reason to not stick with >>> maya.cmds for common tasks. I’ve seen some use the API for performance >>> concerns, but other than that it seems better suited for plug-ins and >>> hacking than it does for scripting of general Maya operations, mainly due >>> to lengthy code and the obscured naming convention inherited from C++. >>> >>> If I had to compare scripting in Softimage versus scripting in Maya, I’d >>> have to go with something like: >>> >>> - Softimage has a poor scripting interface (mainly due to COM) and a >>> rather well-rounded API/Object Model >>> - Maya has a well-rounded scripting interface and a rather poor API >>> (based on what I’ve heard, as I know very little of it myself) >>> >>> What would be your thoughts on this? >>> >>> >>> -- >>> 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/CAFRtmOB1s-FZCcv1HtNV8yoUDm2VN7Liv4x53m74cT528F%3Dnww%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOB1s-FZCcv1HtNV8yoUDm2VN7Liv4x53m74cT528F%3Dnww%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/CANuKW50q6Dg2KVNn88NnpufY1OSPxReDgAgRnG1%2B%3DProx7vALQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CANuKW50q6Dg2KVNn88NnpufY1OSPxReDgAgRnG1%2B%3DProx7vALQ%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/CAPGFgA0Cz9SyXxYbCSWaWCN8-9ONYQLqoTbyTuN9Pta%3Dxfs3-g%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Cz9SyXxYbCSWaWCN8-9ONYQLqoTbyTuN9Pta%3Dxfs3-g%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/CANuKW50jU6Ae62wGS_Qru_T3jbP0r9OWHxR0c%2B%3DpoSC%2ByaD6Mg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
