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
