I think it's better to separate the pymel classes from specific tool-related classes. The pymel classes tightly follow maya's dependency node inheritance tree, feature methods appropriate for each node type. Creating a new node type (using a maya API plugin) and injecting a corresponding class into the pymel namespace should allow you to return instances of that class automatically, without requiring messing with the pymel object instantiation mechanics. But from my experience that is rarely needed. Usually any custom features are required in the context of some special tool, where it isn't too costly to cast the object into a new type (inheriting from the pymel object), or wrapping it with a separate, tool-specific object type.
- Ofer www.mrbroken.com On Fri, Jul 2, 2010 at 11:53 AM, Susanta Dutta <[email protected]> wrote: > Hi, > > Interesting topic here... what PyMel is offering is perfect for more most > of the cases....but to support multiple extensions scenario for a pymel > class if we can get little bit more support...will be helpful .... let me > explain... > > Say like we have two SubClass for Locator class: ChineseDragonLocator and > JapaneseDragonLocator :)....both are developed by two complete separate > development teams....now with current system PyMel can return instance of > only one subclass type (I think the last registered one) registered using > registerVirtualClass method(or something I'm missing here). So if someone > want to use both extensions, With the power of dynamic language and meta > programming it easy to achieve but user have to do some custom coding every > time to force inheritance. If we can do something in default class > registration system, so multiple extended subclasses can be used. Wondering > what if it provides dictionary object to store extensions inside return > object so name conflict issue(if try to implement multiple inheritance) can > be overcome and multiple extended class interfaces( are not under same > inheritance tree) also can be called separately from returned object without > doing any casting in user code? > > cheers > > On Fri, Jul 2, 2010 at 5:45 PM, Paul Molodowitch <[email protected]>wrote: > >> > I've played with the factories example and I can see that it's >> > returning a subclass of the nodeType. This is fine but it does mean >> > any isinstance calls will need to be replaced with issubclass instead. >> >> I'm not sure I see what you mean.... what isinstance calls would need >> to be replaced with issubclass? The idea is that you would use the >> returned class as you would any other pynode class... Transform, >> Locator, etc. Instances of that registered subclass would be >> automatically returned by PyNode('nodeOfYourType') when it met the >> conditions you specify with with _isVirtual >> >> For instance, suppose you did something like: >> >> import pymel.internal.factories as factories >> >> class DragonLocator(Locator): >> """ >> Very handy subclass of Locator used for identifying where Dragons be. >> """ >> >> @classmethod >> def _isVirtual(cls, obj, name): >> return name.endswith("Dragons") >> >> factories.registerVirtualClass( DragonLocator, nameRequired=True ) >> >> newNode = createNode('locator', name='HereBeDragons') >> isinstance(newNode, DragonLocator) >> >> ...the final 'isinstance' will return True. >> >> > Do you think it's wise to register virtual methods onto a base class >> > instead of using the __new__ method to return a subclass? >> > >> > In which case perhaps factories.registerVirtualMethods([funcPoint,]) >> > might be acceptable? >> >> ...I may be misinterpreting what you mean - but if you're asking for a >> way to add >> methods onto, say, the 'regular' Locator class, then no, I don't think >> we'll be providing >> support for that, for two reasons: >> >> 1) It's already easy to do that, if that's what you want to do - just >> 'monkey patch' the >> base class in the sort of way Ofer was talking about. >> >> 2) The virtual subclassing is a much more powerful method of extending >> pymel, as it >> allows for customized differentiation and behavior. >> >> - Paul >> >> > -Dave >> > >> > On Fri, Jul 2, 2010 at 9:26 AM, David Moulder <[email protected]> >> wrote: >> >> I'll try to have a look at that today and get some feedback to you. >> >> Ofer example is also interesting too. So I'll look into it as well. >> >> Ofer, How are you wrapping PyMel then, Are you creating 1 module that >> >> does all the monkey patching? Or have you done something more complex? >> >> >> >> -Dave >> >> >> >> On Thu, Jul 1, 2010 at 10: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 >> >>> >> >> >> >> >> >> >> >> -- >> >> David Moulder >> >> http://www.google.com/profiles/squish3d >> >> >> > >> > >> > >> > -- >> > David Moulder >> > http://www.google.com/profiles/squish3d >> > >> > -- >> > http://groups.google.com/group/python_inside_maya >> >> -- >> http://groups.google.com/group/python_inside_maya >> > > -- > http://groups.google.com/group/python_inside_maya > -- http://groups.google.com/group/python_inside_maya
