rename() and <node>.rename() does not update data returned by node's *Name() or __repro

[chadrik]

From john.d.b...@gmail.com on April 04, 2008 12:57:17

0.7.8, maya 2008, CentOS 4.5

it would also appear that renaming a node causes .longName() to throw an exception.

running this:

ball = polySphere()[0] print ' nodeName: %s' % ball.nodeName() print 'shortName: %s' % ball.shortName() print ' longName: %s' % ball.longName()

print 'renaming...'

ball.rename('foo') print ' nodeName: %s' % ball.nodeName() print 'shortName: %s' % ball.shortName() try: print ' longName: %s' % ball.longName() except: import traceback as tb print tb.print_exc()

print ls(type='transform')

returns this:

nodeName: pSphere1 shortName: pSphere1 longName: |pSphere1 renaming... nodeName: pSphere1 shortName: pSphere1

Traceback (most recent call last):

File "", line 13, in

File

"/mainframe/share/internal/devMaya/2008/release/python/pymel/node.py", line 1390, in longName

return self.class( cmds.ls( self, long=True )[0] )

IndexError: list index out of range

None [Transform('foo'), Transform('front'), Transform('persp'), Transform('side'), Transform('top')]

Original issue: http://code.google.com/p/pymel/issues/detail?id=29

[chadrik]

From john.d.b...@gmail.com on April 11, 2008 14:17:20

this issue should probably just be marked as 'invalid' or 'as designed' or whatever tag you're using to flag non-issues.

just remembered that all the nodes are subclasses of pythons unicode, and as such are immutable, and then recalled reading the section on 'Immutability' in the docs referring to the pymel module itself. RTFM.

assigning the output of rename() to a variable does indeed work as advertised. my bad.

[chadrik]

From chad...@gmail.com on April 11, 2008 22:07:09

in the next version pymel, pynode types will no longer be based on unicode, but on a new object based around the api MObject. the decision ensures the longevity and legitimacy of this project, because it initiates the marriage of maya.cmds and the api, which with the advent of python in maya, is an arbitrary distinction inherited from mel (so long as one is not making nodes or commands). in the short run, there may be a performance hit because maya.cmds functions will need to stringify our pymel MObject nodes. however, we are in talks with autodesk and have conveyed to them the tremendous advantage of making maya.cmds "MObject-aware", so with future versions of maya, and with pymel's own custom listing commands, you will see 100-fold performance gains. also, it solves your immutability quandary. :)

for more on what autodesk can do to improve python in maya: https://code.google.com/p/pymel/wiki/Autodesk

Status: Fixed

[chadrik]

From chad...@gmail.com on February 09, 2009 23:42:27

Labels: Milestone-0.7.x