Sustana, David - If I'm reading you correctly, what you're worrying about is cases where people are developing extensions to be released to then be used by other third parties... and then having issues with two separate 3rd party extensions conflicting?
If so, you're right, that's not something the current custom class extension is good at handling gracefully... and definitely something to think about as a feature at some point. Of course, we're also welcome to contributions if some enterprising soul wants to jump in and take a whack at it themselves... ;) - Paul On Mon, Jul 5, 2010 at 3:33 AM, David Moulder <[email protected]> wrote: > Monkey Patching for the sake of just hanging a function off a pyNode > seems excessive to me. But never the less I wondered how people are > extending pymel in their studios. As pymel is our main tool now I was > wondering how "out of the box extending" has been implemented and how > "used" it was. By the response I guess it's not very common and we > should err on the side of caution before we start monkey patching or > subclass PyNode's. > > Thanks everyone I think we've got what we need. > > Cheers > -Dave > > PS Susanta, is this the type of thing you meant? > > from factories import extend > ExtDependNode: > '''extend a PyNode basetype, this is safe because the extension > will be added > via a sub dict object on the PyNode" > > __namespace__ = "eCom" > > �...@extend: > def someEcomExtensionMethod(self): > '''futile example''' > pass > > A = pCore.selected()[0] > A.someEcomExtensionMethod() > > __getattribute__ would look up the method by default pymel mechanisms > and finally look through the extensions dict? > > or > > A = pCore.selected()[0] > A.ext["eCom"].someEcomExtensionMethod() > > Anyway, I don't think this would be that useful for the reasons > discussed here, but it's interesting anyway > > -Dave > > > On Mon, Jul 5, 2010 at 10:06 AM, Ofer Koren <[email protected]> wrote: >> 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 > > > > -- > David Moulder > http://www.google.com/profiles/squish3d > > -- > http://groups.google.com/group/python_inside_maya -- http://groups.google.com/group/python_inside_maya
