I suppose you could have a .createCmd() classmethod instead of the kw args and leave the current constructor as it is?
I saw this on a PyCon video the other day. It's widely accepted that you should create multiple constructor methods rather then 1 complicated method and where possible stick to already used conventions in the python standard library as a naming convention. Also, in the exmaple above I'd expect the result of the cmd to return a PyNode? pCon = parentConstraint(cube1, cube2, cube3, mo=1, w=1) instead of pCon = PyNode(parentConstraint(cube1, cube2, cube3, mo=1, w=1)) but saying that I have done the later in some instances. -Dave On Wed, Apr 20, 2011 at 4:30 PM, John Patrick <[email protected]> wrote: > Hey, don't let me rain on your parade!! It sounds like you have a valid > point, given how the constructors are set up currently. And I'll agree, it > does feel a little more satisfying to instantiate the classes directly :P > > I think the main downside is that it may be confusing for those new to > PyMEL, since it's a little redundant...but that may not be enough reason not > to support it. > > -JP > > > On Wed, Apr 20, 2011 at 8:02 AM, Paul Molodowitch <[email protected]>wrote: > >> Interesting... and here I was, about to announce that I'd expanded support >> for maya node construction in PyNode class constructors. You would be able >> to pass in a special 'createArgs' kwarg that would be passed to the >> underlying command in create mode. Ie: >> >> pCon = pm.nt.ParentConstraint(createArgs=(cube1, cube2), mo=1, w=1) >> >> would now be equivalent to: >> >> pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1) >> >> I can see the argument of keeping a clear separation between PyNode >> construction and maya node construction, as it helps make clear the >> conceptual difference between the two. On the other hand, PyNode >> constructors already support maya node construction when there are no >> keyword args, and have for a while, so removing support for it is pretty >> much not possible, as it would break too much existing code. So my feeling >> is, if we're going to support it, may as well support it all the way. Plus, >> I guess it just feels more like I'm doing real object oriented coding when >> I'm invoking class constructors. =P Just my two cents though... >> >> Anybody else with an opinion? Should probably get Chad to weigh in on >> this, too... >> >> - Paul >> >> >> On Wed, Apr 20, 2011 at 7:46 AM, John Patrick <[email protected]>wrote: >> >>> Personally, I feel like I wouldn't be served well by having the PyNode >>> class constructor handle node creation. After all, it's the command's job >>> to create the node and hook it into the DG. I think, if anything, there >>> maybe could be a class method that does a createNode() and returns a PyNode >>> instance of that node...but even then, it's pretty easy to do >>> pm.PyNode(pm.createNode('transform')) >>> >>> That being said, maybe there's a situation where using the PyNode >>> constructor like a command would be convenient, I just haven't run into one >>> :) >>> -JP >>> >>> On Wed, Apr 20, 2011 at 7:33 AM, Paul Molodowitch >>> <[email protected]>wrote: >>> >>>> Oops... correction below: >>>> >>>> On Wed, Apr 20, 2011 at 7:28 AM, Paul Molodowitch >>>> <[email protected]>wrote: >>>> >>>>> Hi Subbu - >>>>> Unfortunately, the PyNode classes (such as pm.nt.ParentConstraint) do >>>>> not contain all of the functionality of the corresponding commands (ie, >>>>> pm.parentConstraint or cmds.parentConstraint). In particular, the initial >>>>> creation of the underlying MAYA node must often be done with the command >>>>> form. In fact, the only way it is currently possible to trigger the >>>>> creation of the underlying maya node AND the pynode with the pynode >>>>> constructor is when the PyNode constructor is fed no non-keyword args >>>>> (such >>>>> as when you do nt.ParentConstraint(mo=1, w=1) ). If you need to >>>>> create the underlying node in manner in which you feed in other node args, >>>>> you'll have to fall back on the command: >>>>> >>>>> import pymel.core as pm >>>>> cube1 = pm.polyCube()[0] >>>>> cube2 = pm.polyCube()[0] >>>>> pCon = pm.parentConstraint(cube1, cube2, mo=1, w=1) >>>>> >>>>> In general, my habit is often to use the commands to create, and the >>>>> PyNode class constructors to create PyNodes for already-existing maya >>>>> nodes. >>>>> I agree, though, that it would be nice to expand support for node >>>>> creation >>>>> in >>>>> >>>> >>>> PyNode class constructors to be able to handle these situations as well. >>>> >>>> >>>> >>>>> - Paul >>>>> >>>>> PS - Did you know it's also possible to do the selection of multiple >>>>> objects in a single step? ie, >>>>> select ('pCube1', 'pCube2') >>>>> >>>>> On Wed, Apr 20, 2011 at 2:12 AM, Subbu <[email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> When am trying in Python, Its working as below: >>>>>> import maya.cmds as cmds >>>>>> pCon =cmds.parentConstraint('pCube1', 'pCube2', mo=1, w=1) >>>>>> >>>>>> >>>>>> but in PyMel, Both the following are not working >>>>>> >>>>>> import pymel.core.nodetypes as nt >>>>>> pCon =nt.ParentConstraint('pCube1', 'pCube2', mo=1, w=1) >>>>>> or >>>>>> pCon =nt.ParentConstraint( PyNode('pCube1'), PyNode('pCube2'), mo=1, >>>>>> w=1) >>>>>> >>>>>> "Error: Unable to determine pymel type for 'pCube1' " is coming >>>>>> >>>>>> >>>>>> In single line it is not possible in PyMel, But its working in 3 lines >>>>>> like this: >>>>>> import pymel.core.nodetypes as nt >>>>>> select ('pCube1', r=1) >>>>>> select ('pCube2', add=1) >>>>>> pCon =nt.ParentConstraint(mo=1, w=1) >>>>>> >>>>>> Any one has any idea, so that I can save 2 lines code in this case, >>>>>> Constraints are repetitive in my code >>>>>> >>>>>> Thanks in advance. >>>>>> >>>>>> Subbu >>>>>> >>>>>> -- >>>>>> http://groups.google.com/group/python_inside_maya >>>>>> >>>>> >>>>> >>>> -- >>>> http://groups.google.com/group/python_inside_maya >>>> >>> >>> >>> >>> -- >>> John Patrick >>> 404-242-2675 >>> [email protected] >>> http://www.canyourigit.com >>> >>> -- >>> http://groups.google.com/group/python_inside_maya >>> >> >> -- >> http://groups.google.com/group/python_inside_maya >> > > > > -- > John Patrick > 404-242-2675 > [email protected] > http://www.canyourigit.com > > -- > http://groups.google.com/group/python_inside_maya > -- David Moulder http://www.google.com/profiles/squish3d -- http://groups.google.com/group/python_inside_maya
