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

[GoogleCodeExporter]

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 "<maya console>", line 13, in <module>
#   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 reported on code.google.com by john.d.b...@gmail.com on 4 Apr 2008 at 7:57

[GoogleCodeExporter]

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.

Original comment by john.d.b...@gmail.com on 11 Apr 2008 at 9:17

[GoogleCodeExporter]

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: 
http://code.google.com/p/pymel/wiki/Autodesk

Original comment by chad...@gmail.com on 12 Apr 2008 at 5:07

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by chad...@gmail.com on 10 Feb 2009 at 7:42

• Added labels: Milestone-0.7.x