Why PyMEL?

The Nature of the Beast

Rather than reinvent the wheel, Autodesk opted to provide
wrappers around their pre-existing toolsets: the C++ API and MEL.
By wrapping them they provided an alternate python interface for
each, but the core code that comprises the API and MEL remained
largely the same. The wrappers serve as a (hopefully) thin layer to
communicate between python and the Maya code being wrapped.
The nature of the wraps is slightly different for each.
maya.OpenMaya

In the case of the C++ API, Autodesk went with an open source
wrapper called swig which generates python functions and classes
from C++ counterparts. The python layer rests on top of C++, which
remains the native execution language. During execution, swig
marshals data back and forth between python and C++.
MEL itself is split into two components: commands, and everything
else.
maya.cmds

In the case of MEL commands, which are (effectively) written using

the C++ API, Autodesk wrote the wrapping mechanism themselves
such that MEL commands could also be registered and used in
python as functions. The same command executed in MEL and
python ultimately end up triggering the same underlying C++ API
calls.
maya.mel.eval

In order to allow execution of arbitrary MEL code such as

procedures, Autodesk provided high level access to the MEL
interpreter. This is as simple of a wrapper as you can get: evaluate
a string representing a chunk of MEL code in the MEL interpreter
and convert the result to a python object (string, float, int, and lists
thereof).
So now that python is available in Maya all of our problems are
solved, right? Well, not quite. Since these new modules are just
wraps of the same underlying API and MEL code that weve had all
along and neither were intended to eventually become pythonified,
the syntax that results from this layering of python over MEL and C+

+ tends to be awkward, especially to those familiar with pythons

idioms.
This syntactical awkwardness, particularly in maya.cmds, was one of
the initial inspirations behind PyMEL. Think of it this way: would you
rather read a book that was translated from japanese into english
by a software program like babelfish or by a human who is fluent in
both languages? That is a key difference between an automatic
wrap like maya.cmds and a restructured wrap like PyMEL, which
uses the maya python modules as building blocks to construct an
intuitive, insightful, and pythonic API.

The Paradigm Shift

MEL is a procedural language, meaning it provides the ability to

encapsulate code into reusable procedures ( aka functions ).
(This is probably old news to you, but bear with me, theres a mildly
entertaining analogy coming up ). The term procedural
programming is used primarily in the context of distinguishing a
language from the newer, object-oriented paradigm.
Object-oriented programming adds organization by creating logical
groupings of functions which are accessed from a common object.
If you have used MEL extensively you know you can get pretty far
with procedural programming alone, but there is often an
exponential relationship between the complexity of a task and the
amount of code it will take to complete in MEL. In other words,
progress breaks down once the task at hand becomes too
complicated. Object-oriented code tends to be easier to read and
write, provides the ability to easily create new data types and reuse
code, and ultimately scales better to complex tasks.
To prove my point, heres a quick example that well cover in more
depth later.
procedural:
cmds.getAttr( cmds.listRelatives( cmds.ls(type='camera')[0],
p=1 )[0] + '.translate' )[0][2]

object oriented:
pymel.ls(type='camera')[0].getParent().translate.get().z

See how nicely that reads from left to right? Object oriented
programming isnt necessarily about brevity, its about legibility
derived from structure.

A quick perusal of the more than three thousand MEL commands in

the Maya documentation will give you an idea why object-oriented
groupings are a good idea. MEL is like a tool chest, a wardrobe,
and a kitchen set all dumped into a bathtub everything in there is
useful in the proper context, but youve really got to know what
youre looking for to get anything done. The shame of it is that
Mayas great innovation is that it is itself inherently object-oriented
every scene represents networks of nodes, each with its own
unique abilities and those that it inherits from its super-classes.
Mayas API is object-oriented, too. So how did MEL end up so
crippled?
The original idea behind MEL and the API was to create a tiered
relationship where complex tasks, or tasks where execution time is
of great concern, were to be performed using the C++ API and
bundled into easy-to-use MEL commands. These commands were
in turn to become the building blocks of more generalized tasks
performed in MEL. The API would be the toolset of the superuser
with access to complex types and external libraries whereas the
scope of MEL would be much more limited and thus more
accessible to the average user.
The advent of python in Maya brought a common language to MEL
and the API, and as a result, the clarity of this tiered structure has
become muddied. API classes, MEL commands, and MEL
procedures can be used within the same python script, completely
outside the context of a plugin. Moreover, python manages to
borrow the strengths of both languages: like C++, it is objectoriented and extensible through third party libraries and custom
types, but like MEL, python is easy to learn, protects the user from
certain daunting programming concepts, and compiles at runtime.
Having managed to provide an object-oriented design without a
steep learning curve, python makes the simplicity of MEL seem like
an unfortunate over-simplification.
So, on the one hand we have the C++ API, now easily accessible
from within Python, object-oriented, but too cryptic and verbose for
everyday tasks, and on the other hand, we have a host of
thousands of MEL-commands-turned-python-functions, too valuable
to do without, but woefully unorganized and unpythonic. Which do
we use? How can they work together? PyMEL bridges this gap by

forging a new object-oriented API thats as powerful and easy to

use as python is.

Glossary
MEL

short for Maya Embedded Language, is a scripting language written

for Maya, and with which much of Mayas functionality and user
interface is built. It was designed to be concise, simple, and Mayaspecific.

C++ API
provides deeper access to Mayas internals. With the API you can
create new node types and new MEL commands. Prior to the
introduction of python in Maya, the API could only be used with C+
+.