search replaces names not available in python.

[rudi]

Hi,
So the searchReplaceNames mel command is not available in python
right?
I tryed to run from python like so:
I have 3 joints in my scece named joint1,joint2 and joint 3.The mel
command to replace "joint" to "fingers" is:

searchReplaceNames "joint" "finger" "selected";

So in python I did:

import maya.mel as mm
mm.eval("searchReplaceNames "joint" "finger" ")

But the mel is not well evaluated,beacuse there is the quote sign in
both names joint and finger...I know I should be skipping signs in
order to evaluate it as a string,but I am not succeeding to do it.

Thx

[Chad Dombrova]

this is pretty trivial to do in python without resorting to mel:

[ x.replace('joint', 'finger') for x in cmds.ls(sl=1)]

[Brandon Harris]

yeah, Python has so many string modules is awesome. Mel just doesn't
hold up.

[chrysl666]

its just a sintax error

import maya.mel as mm

command = "searchReplaceNames \"joint\" \"finger\" \"hierarchy\" "

mm.eval(command)

--
http://groups.google.com/group/python_inside_maya

[Judah Baron]

Also worth mentioning here is the strength of using the api for such operations. For instance, it's straight forward to grab all of the MObjects of the nodes you are working on, before renaming them. If you rename a number of nodes in the same hierarchy using a mel-centric approach you need to do some pretty ugly string manipulation to ensure that you don't maintain a reference to a node that was renamed by your action. If you grab the MObjects first, you don't have to worry about this possibility since renaming an MObjects won't change its address.

--
http://groups.google.com/group/python_inside_maya

[Chad Dombrova]

> Also worth mentioning here is the strength of using the api for such
> operations. For instance, it's straight forward to grab all of the
> MObjects of the nodes you are working on, before renaming them. If
> you rename a number of nodes in the same hierarchy using a mel-
> centric approach you need to do some pretty ugly string manipulation
> to ensure that you don't maintain a reference to a node that was
> renamed by your action. If you grab the MObjects first, you don't
> have to worry about this possibility since renaming an MObjects
> won't change its address.

same goes for pymel objects

-chad

[Phil Sloggett]

true, but ensuring your list is sorted by length and checking that an object exists before renaming isnt THAT ugly.

On Fri, Jan 8, 2010 at 1:23 PM, Chad Dombrova <cha...@gmail.com> wrote:

Also worth mentioning here is the strength of using the api for such operations. For instance, it's straight forward to grab all of the MObjects of the nodes you are working on, before renaming them. If you rename a number of nodes in the same hierarchy using a mel-centric approach you need to do some pretty ugly string manipulation to ensure that you don't maintain a reference to a node that was renamed by your action. If you grab the MObjects first, you don't have to worry about this possibility since renaming an MObjects won't change its address.

same goes for pymel objects

-chad

--
http://groups.google.com/group/python_inside_maya

[Chad Dombrova]

> true, but ensuring your list is sorted by length and checking that
> an object exists before renaming isnt THAT ugly.

it is if you're working with shortest unique names and the act of
changing one of the objects in your list causes other names in the
list to become invalid (no longer points to a unique object). and
it's a lot uglier than not having to worry about it at all, as with
pymel.

-chad

[rudi]

Cool.Thanks a lot.