I keep arguing that in the absence of pymel we'd just end up writing our own private maya.cmds wrappers/util-libraries/helper-modules/bug-fixer-modules sooner or later (that's Chadrik's story pretty much). But then you don't have the benefits of a collaborative project, the expertise of solid python architects that design and abstract the library to fit all uses, and the much larger user community to test and debug it.
pymel is also useful as an abstraction layer between the pipeline tools and the underlying maya implementation, which actually allows a studio for much greater flexibility when it comes to upgrading maya versions. By having tools go through the pymel layer one is able to change some default behaviors based on the pipeline needs in a centralized manner. - Ofer (a biased pymel contributor...) www.mrbroken.com On Fri, Dec 11, 2009 at 10:51 AM, David Moulder <[email protected]>wrote: > Hi daganael, > > Eurocom went through a similar debate when we started to move from mel to > python. At the time we were just learning OOP with python. We struggled to > write Python in a OO way because of the cmds wrapping. We also had problems > mixing our python code with our extensive mel code base. pymel.melGlobals[] > and pymel.mel.myMelScript() realy went a long way to bridging the gap for > us. Since we started to play and investigate Python it was a NATURAL > progression/realisation that we could be doing things much more > intutetively. So 6 months of writing code with python the pymel > argument/discussion we were having internally faded. Lets just say the > pro's out weighed the con's. > > My 2 pennies, > > -Dave > > > > > On Fri, Dec 11, 2009 at 6:24 PM, Paul Molodowitch <[email protected]>wrote: > >> Ok, well, first of all, let me say I'm a contributor to the pymel project, >> so I'm hardly an unbiased opinion. =P >> >> However, here's my take: >> >> First of all, as far as having issues... well, I could go on about how >> hard we've worked to try and eliminate bugs (we currently have ~ 1450 unit >> tests, I believe)... and mention that it's been used successfully in major >> studios... but any software has bugs. However, I would argue that, despite >> the lack of official support, it's actually easier to fix / find a >> workaround for a pymel bug than it is for a "normal" autodesk one. >> >> First of all, there's the fact that it's OpenSource - all your normal >> debugging options are open to you, and if you find the root source of the >> problem, you can fix it yourself. With a regular maya command, it's >> generally a black box... and even if you know the exact conditions that >> cause the problem, can reproduce it reliably, and submit a ticket to >> autodesk... well (assuming the ticket gets noticed and given a high-enough >> priority to get fixed), simply due to the nature of Maya's corporate release >> schedule, you'll likely have to wait a while before you see the fix >> incorporated into Maya. Due to the fact that we're open source, you can >> access any pymel fixes as soon as we make them. >> >> Secondly, consider that while, yes, pymel will inevitably have bugs in >> it's own code, it ALSO fixes/hides a number of bugs in maya's own code. >> Plus, it allows you to avoid, ah, 'confusing' elements of maya's python >> implementation which, while not technically bugs in and of themselves, are >> likely to introduce bugs of their own. (*cough* MScriptUtil *cough*). Then >> there's the simple fact that it can drastically reduce the number of lines >> of code it takes to write a program... and more lines of code mean a higher >> the probability of a bug. >> >> Remember, too, that pymel is NOT an either-or question. It's another tool >> in your toolset. If you are having problems with pymel (or suspect you >> are), you can quite easily fall back on the standard maya.cmds, or mix those >> in with pymel commands. >> >> As a final note on the whole 'support' question, while we may not be an >> 'official' support mechanism, Chad and I try to be as helpful as we can... >> as do a large number of other folks on this list. >> >> As far as pymel going 'poof'... well, of course, nothing is ever >> guaranteed. But the chances of pymel dying at anytime in the near future >> are, ah... slim, to say the least. It's very tightly integrated into our >> pipeline here at Luma, so even if nobody else were using it, we would keep >> on developing it. And Autodesk is very aware of pymel's existence, and it's >> user base. We have a fairly good relationship with Autodesk, and they know >> that doing something which would break pymel is not in their best interest. >> >> Anyway, that's my take... I'm sure others have different views. =) >> >> - Paul >> >> >> >> -- >> http://groups.google.com/group/python_inside_maya >> > > -- > http://groups.google.com/group/python_inside_maya > -- http://groups.google.com/group/python_inside_maya
