hi all, got a little survey for you. those of you who have tried out pymel 1.0 i'm sure have noticed that it wraps part of the maya package (this is what makes the install more difficult, because it has to come before the "real" maya package). we've got good reason to do this: better integration with maya, bug fixes, etc.
so far what we've fixed is important to pymel, and while it fixes a major bug in maya, it's still probably not something that end-users will even notice. however, there's another problem that we could fix, but people will definitely notice it, and i want opinions. if you've got a large collection of interdependent python modules it's very difficult to only upgrade only some of your modules to pymel, because maya.cmds will error if you pass it a PyNode, Vector, Matrix, etc. the way that we've handled that in pymel is by adding a __melobject__ method to all of these non-compatible types that returns a mel-friendly representation: pynodes return strings, matrices return flat list of 16 floats, etc. then we've done a low-level wrap of maya.cmds in pymel.internal.pmcmds, that calls __melobject__() on any input arguments. this module, pymel.internal.pmcds, is the basis for all other command wraps. so, the question is: should we add this light wrapper directly to maya.cmds in pymel 1.0? advantages: ensures compatibility between results passed between scripts that use maya.cmds and those that use pymel disadvantages: exceptions will come from one frame deeper, which might scare and confuse some people this __melobject__ mechanism also opens up the possibility of the end user adding this simple callback to any of their own complex datatypes that they intend to pass to maya.cmds. we could make it an optional install, but that gets tricky.... -chad -- http://groups.google.com/group/python_inside_maya
