I get into the Maya python API in my Python For Maya Artists Vol 2, on cmivfx.com Chad Vernon has his newer and much longer API tutorial but I think its all C++ if I am not mistaken? Also you can find a handful of free tutorial online with much more specific topics.
On Oct 3, 2012, at 8:14 PM, Panupat Chongstitwattana <[email protected]> wrote: > Sorry for going off topic. Is there any learning materials for Maya python > API? > > > On Thu, Oct 4, 2012 at 7:31 AM, Marco D'Ambros <[email protected]> > wrote: >> really good docs, agree 100 % >> >> just a little clarification, >> if you ask me if I prefer >> import maya.cmds as cmds >> instead >> from maya import cmds >> >> I prefer the second one...I'm agree that cmds it's pretty common name, and >> could be confusing but we are using cmds with the first example as well. >> >> in general with name as cmds, core, or similarly a prefer to use the full >> "path": >> >> import maya.cmds >> import pymel.core >> >> it's more easy when I'll go to read back my code after months/years or when >> I read the code write form someothers. ( of corse it there are the only >> library imported I can understand to use core, cmds...) >> >> ps: for the api i still use from maya import OpenMaya, because I find >> OpenMaya pretty clear ;) >> >> >> -------------------------------- >> Marco D'Ambros >> phone : (+61) (0) 435809628 >> web : www.marcodambros.com >> mail : [email protected] >> >> >> >> On Thu, Oct 4, 2012 at 12:48 AM, Python inside Maya <[email protected]> >> wrote: >>> I see, so the main justification is name space clashing. >>> Thanks Serguei >>> >>> >>> On Wednesday, October 3, 2012 1:00:12 AM UTC-7, [email protected] >>> wrote: >>>> The rule of thumb with Python imports is to avoid name clashes. This is >>>> why you sometimes see people advise against from import style. >>>> This is especially true if your modules are too generic (which cmds >>>> certainly is). >>>> >>>> In general stay away from from import * unless the API you are using >>>> explicitly says it's ok to do so (ex. TkInter). >>>> Another exception is if you have a specific purpose for doing so, like >>>> setting up a settings scheme using python files (ex. Django). >>>> >>>> So your choice often depends on what libraries you're working with, where >>>> and how you expect your code to be used and finally personal preference. >>>> >>>> I think this sums it up pretty well: >>>>> Use import x for importing packages and modules. >>>>> Use from x import y where x is the package prefix and y is the module >>>>> name with no prefix. >>>>> Use from x import y as z if two modules named y are to be imported or if >>>>> y is an inconveniently long name. >>>>> Do not use relative names in imports. Even if the module is in the same >>>>> package, use the full package name. This helps prevent unintentionally >>>>> importing a package twice. >>>> >>>> >>>> >>>> On Tue, Oct 2, 2012 at 11:47 PM, Paul Molodowitch <[email protected]> >>>> wrote: >>>> > Hmm... if it's a deep hierarchy, i generally prefer >>>> > >>>> > import my.module.hierararchy.wantedModule as wantedModule >>>> > >>>> > ...as opposed to having to use the full hierarchy all the time. It's >>>> > still >>>> > easily discoverable where it came from, you can still do easy >>>> > search/replace >>>> > if needed, etc. >>>> > >>>> > As for >>>> > >>>> > from maya import cmds >>>> > >>>> > vs >>>> > >>>> > import maya.cmds as cmds >>>> > >>>> > ... I tend to prefer the second, because it makes it clear that >>>> > maya.cmds is >>>> > a module. Ie, if you do: >>>> > >>>> > from maya import cmds >>>> > >>>> > ...cmds could be anything - a function, a dictionary, a module, etc. It >>>> > also has the added bonus that if you ever want to do text searches >>>> > through >>>> > your code base, you still have the whole module name in one piece - ie, >>>> > it >>>> > will be found if you just search for "maya.cmds". (Of course, if you >>>> > want >>>> > to be certain you found all uses of a given module, you need to search >>>> > for >>>> > both forms... but still, I find it nice.) >>>> > >>>> > Just my 2 cents... >>>> > >>>> > - Paul >>>> > >>>> > >>>> > On Tue, Oct 2, 2012 at 11:16 PM, Marco D'Ambros <[email protected]> >>>> >>>> > wrote: >>>> >> >>>> >> I'm for the second one >>>> >> from maya import cmds >>>> >> >>>> >> I don;t see the point to use >>>> >> import maya.cmds as cmds >>>> >> >>>> >> -------------------------------- >>>> >> Marco D'Ambros >>>> >> phone : (+61) (0) 435809628 >>>> >> web : www.marcodambros.com >>>> >> mail : [email protected] >>>> >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Oct 3, 2012 at 11:44 AM, Jesse Kretschmer <[email protected]> >>>> >> wrote: >>>> >>> >>>> >>> I would certainly advise against "from bigpackage import *" as the >>>> >>> wildcard could lead to namespace collision and general funny business. >>>> >>> >>>> >>> Let me hijack this topic with another question about imports. Which is >>>> >>> more correct; "import maya.cmds as cmds" or "from maya import cmds"? I >>>> >>> prefer the latter, but mostly because it is fewer keystrokes. >>>> >>> >>>> >>> >>>> >>> On Tue, Oct 2, 2012 at 6:09 PM, Justin Israel <[email protected]> >>>> >>>> >>> wrote: >>>> >>>> >>>> >>>> Why do these sites advise against "from ... import ..."? >>>> >>>> >>>> >>>> >>>> >>>> On Oct 2, 2012, at 5:01 PM, Python inside Maya <[email protected]> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> I would love to hear some thoughts on handling python imports, >>>> >>>> specifically in larger code depots with deeper hierarchies. >>>> >>>> The way I see it, the safest way to go is to import >>>> >>>> company.teamA.whatever.module >>>> >>>> >>>> >>>> The big draw back that I see is that the code becomes bloated with >>>> >>>> company.teamA.whatever.module.class().method() >>>> >>>> From that perspective - from company.teamA.whatever import module - >>>> >>>> seems like a better choice >>>> >>>> Then code reads module.class().method() >>>> >>>> >>>> >>>> This gets more and more problematic, the deeper the code depot >>>> >>>> hierarchy >>>> >>>> is/gets. When reading up on Python imports several sites advice >>>> >>>> against >>>> >>>> using the from-import technique. >>>> >>>> Any input is appreciated, >>>> >>>> >>>> >>>> Thanks, >>>> >>>> /Christian >>>> >>>> >>>> >>>> -- >>>> >>>> view archives: http://groups.google.com/group/python_inside_maya >>>> >>>> change your subscription settings: >>>> >>>> http://groups.google.com/group/python_inside_maya/subscribe >>>> >>>> >>>> >>>> -- >>>> >>>> view archives: http://groups.google.com/group/python_inside_maya >>>> >>>> change your subscription settings: >>>> >>>> http://groups.google.com/group/python_inside_maya/subscribe >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> view archives: http://groups.google.com/group/python_inside_maya >>>> >>> change your subscription settings: >>>> >>> http://groups.google.com/group/python_inside_maya/subscribe >>>> >> >>>> >> >>>> >> -- >>>> >> view archives: http://groups.google.com/group/python_inside_maya >>>> >> change your subscription settings: >>>> >> http://groups.google.com/group/python_inside_maya/subscribe >>>> > >>>> > >>>> > -- >>>> > view archives: http://groups.google.com/group/python_inside_maya >>>> > change your subscription settings: >>>> > http://groups.google.com/group/python_inside_maya/subscribe >>>> >>>> >>>> >>>> -- >>>> Technical Director @ DreamWorks Animation >>> >>> -- >>> view archives: http://groups.google.com/group/python_inside_maya >>> change your subscription settings: >>> http://groups.google.com/group/python_inside_maya/subscribe >> >> -- >> view archives: http://groups.google.com/group/python_inside_maya >> change your subscription settings: >> http://groups.google.com/group/python_inside_maya/subscribe > > -- > view archives: http://groups.google.com/group/python_inside_maya > change your subscription settings: > http://groups.google.com/group/python_inside_maya/subscribe -- view archives: http://groups.google.com/group/python_inside_maya change your subscription settings: http://groups.google.com/group/python_inside_maya/subscribe
