Not sure how this competes with the 'registerVirtualClass' technique, but
I've been using studio-specific wrapper module around pymel which
'monkey-patched' certain classes and added desirable studio-specific
functionality:
(The example uses the old pymel 0.7x package structure, but the idea should
be the same)
----<my_pymel.py>----
from pymel import *
import pymel as __pm
def isSelected(self):
return bool(__pm.ls(self.longName(), sl=True)) # 'ls' will
return an empty list if self isn't selected
__pm.DependNode.isSelected = isSelected # add the new
method to pymel's original DependNode class
----<myTool.py>----
import my_pymel as pm # use the wrapper instead of going directly to
pymel
for node in pm.ls():
print node, node.isSelected()
-----------------------------
The process of patching (adding new methods to externally defined classes)
can be automated using some meta programming techniques (decorators mainly).
I'm sure Paul or Chad could comment further on the pros and cons of this
(and perhaps correct my example to fit with the latest pymel version?...)
- Ofer
www.mrbroken.com
On Thu, Jul 1, 2010 at 2:24 PM, Paul Molodowitch <[email protected]> wrote:
> It sounds like factories.registerVirtualClass should do what you
> need... I guess you already saw the example, so that should explain
> how it's used. The only word of warning is that we consider it an
> 'experimental' feature - I've used it before, and it worked, but I
> haven't used it recently, or ever really tested it extensively.
>
> That said, though, we'd love for more people to try it out, and put it
> through it's paces.
>
> - Paul
>
> On Thu, Jul 1, 2010 at 9:49 AM, thirstydevil <[email protected]>
> wrote:
> > Salute.
> >
> > Here at eurocom we've been debating how to design our python package
> > with development with pymel in mind.
> >
> > As we're becoming better OO python programmers we're using pymel more
> > and more. Leaving our old MEL libraries behind and slowly converting
> > or writing our pipeline in python with pymel.
> >
> > We've created our own package that use's pymel. The design of that
> > package is something that we've been debating recently in our
> > department. One of the main discussions is how to extend a pymel base
> > class without sub-classing. Because:- Where do we subclass in our
> > package design or even should we subclass? What do we do when we want
> > our subclass to always be returned by pymel?
> >
> > One of our more senior programmers has suggested a extension system
> > for pymel where by a PyNode would bind extension methods to it's
> > respective PyNode class from an extensions module.
> >
> > def isSelected(self):
> > import maya.cmds as cmds
> > return self.longName() in cmds.ls(sl=True,l=True)
> >
> > A = pCore.selected()[0]
> > meth = types.MethodType(isSelected, A, A.__class__)
> > A.isSelected = meth
> > A.isSelected()
> >
> > I like the idea and was wondering how other's have integrated PyMel
> > into their studio Libs and how they handle their package design with
> > pymel in mind. As sometime the line between our pipeline package and
> > extending pymel is blurred. Which is why the pymel extension system
> > came to mind.
> >
> > Looking at the customClasses example I was wondering if we can already
> > do this with the factories module?
> >
> > -Dave
> >
> >
> > --
> > http://groups.google.com/group/python_inside_maya
>
> --
> http://groups.google.com/group/python_inside_maya
>
--
http://groups.google.com/group/python_inside_maya
