That's what I refer to with open Maya 2. It's about as pythonic as writing Haskell on punch cards :) On 6 May 2014 23:16, "Marc-Andre Belzile" <marc-andre.belz...@autodesk.com> wrote:
> There is also Maya Python 2.0 which is more pythonic than v1.0. However, > the class set in v2.0 is not as exhaustive in v1.0. > > -mab > > From: softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane > Sent: Monday, May 05, 2014 8:42 PM > To: softimage@listproc.autodesk.com > Subject: Re: Softimage Python versus Maya Python > > 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<mailto: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. > >
