Is It Possible To Source A Python Script Like A Mel One?

[kzax]

I have a syntax error when I try to source a correct python script, tested in the editor.
Thanks.

[joojaa]

import

but that does not reload it

theres a eval taht you can use for that see the python docs its nbamed like somthing evelexec file or something

Anyway it might still error because the console works in different namespace.

[john-creson]

Joojaa is right...

You need to import a python script, you can't source it, sourcing is mel only.
The error you are getting is telling you that the script is not good MEL.

save your python script in your local maya/scripts folder (or other folder on your sys.path)
{what folders are on my sys.path?}
import sys
sys.path
(out comes a list with all the paths)
(do the following to add a new path to sys.path.)
sys.path.append("C:\newPath")

Once your script is in a folder that mayapy can find...

import goodScript

and call a function from that script. (if you script without functions, like you might write a shelf button perhaps, the import will work once, and the reload will work subsequently)
In a very melly way you can name your function the same as your script.

goodScript.goodScript()

When you change your script and you haven't re-started Maya you need to reload your script

reload(goodScript)

[kzax]

thanks a lot for your answers, but this problem made me wondering if python was the best way for me to start programming in maya. I tried to start with python because it seem, and it is I think, to be a powerful langage with a nice future, but the main reason was his presence in xsi and blender too... Though I tought it will be great to learn one langage to "play" in three 3D packages
But after the first problems I met, I start to read a lot lot of posts on python subject, with all the neat advices of jooja rob daniel and friends..., and finally I decided to begin at the beginning, I mean I'm going to start learning MEL, and C++. Less presumptuous, far more realist.
I realised too that to be able to well program in a 3D package I have to know the better that I can how it is working "under the hood", and maya is a so big "play field"....so : mel and C++ for me, for today and the next monthes (next years?).
I realised too that python was "only" a layer over mel, or a layer over c++ for plugins, but not a direct langagae for maya, if I'm not wrong, so why not start with the more direct langages.
Thanks again for your help, I think you'll see me on the mel and c++ forums soon
Philippe.
PS : I'm not used to write in english, so please be lenient

[joojaa]

They are as direct as mel or c++, however mels greatest power lies in the echoer and bulk of example code that ships with your maya. C++ is about speed of execution but its not fun to type python is much more easier for this si suggest python.

But the real point is that in maya theres no direct methodology, all maya does s in sort of barred in a c container of some kind. You have no direct access to maya at any point of your lifespan. Nor do you really want to either.

The big problem arises when you think you DO have direct control over things and then you start thinking your code is equal to theirs. This is especially true to python scripting where the border can be confusingly gray.

Programming maya is different form programming your ouwn stuff. You can only extend maya once you know what maya is all about.

[kzax]

ok, I'll work mel for the most things I can do in maya.
If I understand well your saying, it would be possible to work with mel for the max stuffs, and then python for plugins and create nodes and so on? The speed loss would be the only disagrement with python against C++?

[john-creson]

As long as my scripts were more like macros I'd stay in MEL.
While you're working out bits and pieces of Maya that demand you work back and forth with the echoes in the scriptEditor and the interactive Maya, MEL is easiest to bang out.
The moment I wanted to do anything with variables and structure (for loops, if this then thats, functions(procs in MEL)) I'd flip back into Python. The ability to convert one command from MEL into the equiv in Python is quick to pick up and you can flip back and forth in the online Help for commands between MEL and Python.
The Python variables are very forgiving. The structure is easy to write and read and write again. Python Lists are fantastic.

If you're halfway there in the example code, and the MEL makes sense to you, it'll probably be quicker to edit than rewrite.

The concern over the speed loss with scripted plugins may be overstated. If you write something that needs more speed, then look into it. Often scripts and scripted plugins are for speeding up and standardizing mundane human interactive jobs, and they do this quite well.

[joojaa]

Well yes c++ difference only comes into play when you start to write nodes that actually participate in a major computation, OR your project is huge. Because c is a strongly typed language it may actually warn you fr before you do something stupid.

both the scripting interfaces are like generals who command people to do stuff, whereas both of the api interfaces are like grunts whose job is to run as fast and do the dirty work. Now instructing things on the level of the general is much more fun and productive than starting to instruct the grunts. Especially since when instructing grunts you need to build a genarl level vocabulary too.

So on script level the command might be

CODE
change wheel

but the grunt level isntruction is something like this:

CODE
change wheel:
  find indicated car:
  check what tools are at hand
  find new wheel
  if proper tools and new wheel and wheel on car:
    pick them up
    go to car
    lift car with jack
    open bolt 1
    open bolt 3
    open bolt 2
    open bolt 4
    remove wheel
    get new wheel
    close bolt 1
    close bolt 3
    close bolt 2
    close bolt 4
    report back
  else:
    complain

now you STILL need to call the general level command to get anything done, but also need to do the gruntwork.

However its not entirely smart to make the general do the grunt work himself because he is much slower to do stuff without his grunts than with them. So once you reach the limits of your general dont program him to do the grunt work because thats not what he is there for. Also the general is fat, and proud so he cant reach all areas. And like in real army once the general starts to individually command each and every grunt it gets inefficient and hard to maintain the information. And off course the subordinates already maintain this info so no idea in double book keeping ask the subordinate for the info.

Mel has this constraint much more bang on than the python, because the area is gray you may plow directly into the grunt area just to notice you are there but are also wery deep in it so converting the code is starting to be pain because yes its python, but the api isn't the same thing it requires a different set of thinking. So in mel your actuually cosntarined to thinmgs, once it gets tedious you KNOW its notreally a mel job. Whereas in python you will miss this if your not so familiar with how mayas organized.

So its fine if he has a few lists, but once he starts to have some algorithmic code its best to start looking at either the python api intetaface or c++ api interface. SDimply because mayas script inetfaces aren't designed for doing computational work. They are designed for assembling computational factories form nodes.

the general division is as follows:

gui-> script
gui automation-> script
export -> api
dg and dag computation-> noscroipt expression or api
View port stuff other than huds-> api
shader nodes ->api / mr api (mentalray shader nodes are excluded form maya api)

PS: a python list is exactly like a mel array, id oly switch to python if i need objectual dictionaries honestly. Even then im inclined to think this is work for the api section.

PPS: mel is much more compatible than python between versions!

[john-creson]

This is a great way to think about Maya - scripting vs api When do I need to make the leap? You are right about MEL, you make the leap when you can't get any further in MEL.

Being able to fiddle around in Maya, exploring the API stuff in Python like I can work out scripting is really nice.

Yes a python list is exactly like a mel array and that is one of the reasons they work so nicely in Maya. Being able to get at the last object picked in the selection list without having to declare a list variable or break out that first string is really sweet. (though you may want to push your list into a variable first so you can pick it up again later on)

print maya.cmds.ls(sl=True)[-1]

[kzax]

nice example with the general and his grunts!
So MEL is the base, and if I smash my head against his walls, I have to make the leap toward the API.
So remain a critical choice for the api : C++ or python.
I understood that C++ is faster but harder to read and write, but can we achieve exactly the same goals with both? If the gain of speed is not really huge, I think I'll go toward python, because I actually made a glimpse of the powerful lists system of python, and his clarity too.
Thanks again for your explanations.

[joojaa]

QUOTE(kzax @ 11/28/07, 06:16 PM) [snapback]277155[/snapback]
I understood that C++ is faster but harder to read and write, but can we achieve exactly the same goals with both?

its just a binding for the same thing so theyalso do the same thing. Only one or 3 things arent exposed to python.

QUOTE
but harder to read and write,

Well its a much more low level language, so you can really feel the metal to the computer so to speak if you wish to do so. This also requires you to understand computers quite well.

QUOTE
you make the leap when you can't get any further in MEL.

actually you do it a lot sooner than that but in mel you will start to feel the pain in the sheer volume of code you will start making.

ps in mel print maya.cmds.ls(sl=True)[-1] = print (ls -sl -tl 1); wich is about as short.