I need that to work but in Python. I have tried countless variations of the code, even using maya.mel.eval but I haven’t had any luck getting it to work. I’ve tried checking google but came up short there too. Any help would be awesome, even if it’s just a suggestion. :):
Python is really modular by nature, as such you can specify which parts of the code base you want to utilize. This is done via importing…
import maya.cmds
imports ALL the commands into the default namespace.
import maya.mel as mm
imports just the mel commands within python into the mm namespace.
That modularity with importing combined with namespaces makes your code shorter to write and more secure. Tons of commands in the default namespace can cause issues.
import maya.cmds as cmds - That’s the convention I picked up and use. This way I can use cmds.sphere(blah, foo) vs maya.cmds.sphere(blah, foo)
I’ve come to MEL and python from not a programming background, so someone please correct me if I’ve misspoken technically.
I’m under the impression that maya.cmds certainly brings in all maya commands (for the most part, some of the string functions and junk are stripped because they’re useless), but maya.mel is only used to call the mel eval command.
[QUOTE=UncCheezy;7563]Not too sure what you mean by more secure…Can you elaborate on that?[/QUOTE]
Probably meaning that you can avoid an import that overwrites an existing name:
from maya.cmds import *
would create a reference to a select() in the global, which isn’t too bad initially until you do something like
from select import select
Now select() refers to the version imported from the select module vs
import maya.cmds as mc
which creates mc.select().
Definitely good to come up with a set of blessed namespaces for your studio/team, at 343i we allow:
import pymel.core as pm
#or
import pymel.all as pm
# pymel.all is discouraged for production, usually we only allow this for prototyping and as the result of conversion
# scripts should be scaled back to pymel.core if possible before final code review
Slightly off topic but related, probably doesn’t hurt to have a standard order for importing either. Ours goes something like (off the top of my head):
# standard lib
import os
# external lib
import scipy
import pymel.core as pm
# C#
import clr
import System.Collections.ObjectModel
# internal lib
import animation.maya.api
import character.export
# siblings
import api
# plugins, privates, constants, etc
Seems like alot, but when dealing with code from numerous sources, consistency is key. In a pinch, PEP-8 is your friend.
I’m so nit picky with my code, I have tried to go through someones code that doesn’t care what it looks like, and it’s a nightmare. I just wish I was as quick with MEL as I am with Python. Otherwise I could avoid running into problems where Python has no idea what I am trying to do cause it’s a MEL only command. :laugh: