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]<javascript:>> 
> 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]<javascript:>
> >
> > 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] <javascript:>
> >>
> >>
> >>
> >> On Wed, Oct 3, 2012 at 11:44 AM, Jesse Kretschmer 
> >> <[email protected]<javascript:>> 
> 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]<javascript:>
> >
> >>> wrote:
> >>>>
> >>>> Why do these sites advise against "from ... import ..."?
> >>>>
> >>>>
> >>>> On Oct 2, 2012, at 5:01 PM, Python inside Maya 
> >>>> <[email protected]<javascript:>
> >
> >>>> 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

Reply via email to