What im trying to say is that, because the api code is so much more flexible and pythonic it does make sense to sit around and THINK when to change suite. But a python programmer might not notice it. My point is not about the practicality of wirting all in one code. After all ist not more work to wirte maya cmds in mel than in python.
Now somebody says but python is so much better programming environment, well meybe. But did you ever consider to only do the computationally intensive part as API code and rest in mel/python.cmds in sepaerate file. At least that way your code would integrate better in maya.
This way no matter whether the user wanted to use mel or python they could. After all mel is here to stay. Because its much better journal language. At least until chadrik makes a mel to python echoer taht always works right. (its not impossibly ghard mind you)
By the way maya echoes whatever something happened to be written in. But yes it should echo both. Its just taht you cant get rid of mel in LOONG while because the buulk of maya gui is mel. And thus we all need to read mel to make changes in that gui.
So my comment is more aimed for the list of lists: if one uses lists of lists one should consider doing so in the api.
QUOTE
that's kind of like saying that there's no point in writing a function of your own, because you can always use builtin python functions.
And if the built in does the job you should prefeer to use it as the pythons code has a 1:100 penalty towards the c code command binding. The only reason youd write a function is that you dont have the exact function you need.
QUOTE
yes, you can do everything that maya.cmds does using api, but it would be a ridiculous amount of work to replace every mel command with api.. after all, under the hood maya.cmds is api code.
Well not exactly, its autodesk internal code which means you or i don't necessarily have access to that api. There are several mel commends that dont have acces to api equivalents. For example: all gui calls.
QUOTE
maya.cmds to accept MObjects would be a huge step toward integrating these two systems.
arrgh argh argh. do you know how much havoc that would cause on the regular user, when the average API user screws up on this every now and then. Well youd want to get something like MObjectHandles instead.
Anyway the changes needed just show the point of it all very clearly. There was never any point in just proting mel into python. Also in teh same breath there was a design reason why mel and the api didnt doboth the same thing.
QUOTE
i'm curious what you mean by this. what part of the interface is in flux?
Well if you look at differences between maya 8.5 and 2008 pythons you will notice they did make some slight structural changes. And i dont think they have locked it yet. Mel is more or less locked already.
And offcourse if your changes ever go trough all or most of written pyyhon code should be revised.
QUOTE
would be a ridiculous amount of work to replace every mel command with api.
Yes but taht dont mean it shouldnt be done that way!
I mean its even more rediculous amount of work to stop using carbon based fuels, but still it has to be done.
PS: I have NOTHING against python, its just that those who unlimitedly hail python have clearly misunderstood the entire execution environment, Just because certain things now are much much easier does not mean youve traded in for a much harder system to use.
So what i advocate is So code where it makes sense, to do so you must know the bounds. And ultimately this brings most flexilility and practicality.
So me for example i still wirte all ad hoc scripting in mel, but do all real programming efforts in python and only convert the small parts that are bottlenecks to C++. This also supports best all the users out here that know mel.
Also knowing python allready does not amke one a good maya scripter, unfortunately. But then again good maya scripting skills dont make you a database guru.