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
