Yeah, I can agree with pretty much all of it. It's a shame, because coverage and performance are very good, but the fact there is no hand crafting of a higher thin layer makes it horrendously clunky.
With just a little bit of additional effort it could actually be very suitable for a lot more than it is suitable for now, but there doesn't seem to be a lot of interest in improving and extending the bindings, which ironically leaves the Python wrapper less friendly to read and operate than the C++ equivalent. I think I officially hit breaking point a few weeks ago at the hundredth (literally) time in what should have been a simple script I had to explicitly cast and recast across multiple variables the same damn data, and then handle every-single-F'ing-instance of a return explicitly. God forbid various adaptive set and get methods and constructors that work perfectly in C++ are wrapped, you can only use the explicitly type handling ones instead in Python, which makes any upstream change of a type combined with Python's eco system an absolute nightmare. If you're mostly doing pipe work that's far enough removed from the scene data and the DG, or has only minimal and simple interaction, you're mostly OK though. On Tue, May 6, 2014 at 9:12 AM, Serguei Kalentchouk < serguei.kalentch...@gmail.com> wrote: > That certainly holds true if you intend to do any plugin development. > For all the pipeline / glew / build code you will still need to operate > within Maya Python unfortunately. > > Otherwise the Python implementation in Maya is very straight forward but > you have to make your piece with the fact that it is not OOP (not > considering PyMel). > So without any custom involvement on your end it's basically just > functional programming with logs of string manipulation. > On the bright side Maya's command module is pretty substantial in terms of > its breadth and depth so you have little limitations in terms of what you > can do. > > If you want to get back some OOP sanity then you're welcome to try PyMel > although it has it's own issues and quirks. > I've ended up writing my own wrapper that covers 90% of my use cases. > >
