Well, as Dave and Susanta may have hinted, I've already got an outline approval from the directors here at Eurocom to allow us to comit into a Eurocom Pymel GIT branch, open source isn't something that they're particularly comfortable with but in this case it makes sense... and maybe for some of the issues that have come up internally that's possibly an easier solution.
Over the last few weeks I've hit 2 or 3 cases where it would be easier to just extend Pymel. AnimLayers for example, there's no method to retrieve the objects from the layer at the moment, yes, only 3 lines of code but then it's something we have to maintain and remember that we've got a function to do it over and above the pm core. I think there's been about 2 or 3 namespace / referencing issues / features also and a bug catch which was posted up on here. It's a tough one, at what point is a class method something which is specific to you're pipeline and not generic? What we're concerned at is that if we comit back to Pymel, how much work it might be to merge any new Git releases back in especially in cases where maybe we strayed too far away from Pymel's ideals and you guys decided not to take the extensions? I guess we won't know until we try though... With the stuff Dave's talking about, using the virtualClass to extend, I guess we isolate ourselves from future change, but then we're not actually helping you guys, or extending the Pymel core... and that's not the intention, Pymel's changed the way work and it's really appreciated. Mark On 5 July 2010 20:17, Paul Molodowitch <[email protected]> wrote: > 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 > -- http://groups.google.com/group/python_inside_maya
