Python imports style question

[BackRaw]

Hi,

I'm wondering which way of importing a Python3 module is more appropriate if you only need 1 or 2 functions from it, like random.randint() and random.uniform():

#1

Syntax: Select all

import random 

rand_int = random.randint() 
rand_float =random.uniform()

#2

Syntax: Select all

from random import randint
from random import uniform 

rand_int = randint() 
rand_float = uniform()

I guess technically it doesn't make any difference. But what's the "SP Way"? :)

[satoon101]

From the Coding Style thread:

• Do's and Don'ts of Importing (the use of "Good" and "Bad" just show what is/isn't acceptable for "this" project. other people prefer to use the opposite, which is perfectly fine):
  • Never import "all" from a module:[PYTHON]# Bad
    from something import *
    
    # Good
    from something import one_object
    from something import second_object[/PYTHON]
  • For "most" imports, import each object individually, and on a separate line:[PYTHON]# Bad
    from os.path import dirname, join, curdir
    
    # Good
    from os.path import dirname
    from os.path import join
    from os.path import curdir
    
    # "Ok", but use only when necessary
    import os.path
    import sys[/PYTHON]

I am a proponent of absolutely never using 'from x import *' as it is highly implicit and never shows objects actually being defined within the scope of the current module. Again, using 'import x' and directly using x's attributes is fine, but it is preferred for this project itself to use 'from x import y'.

For whatever reason, I typically don't adhere to this when importing from the sys module. Many of the objects in sys are fairly ambiguous and have names that could easily be names of other objects either imported into the current module or defined in the current module.

Some items require you to import the package/module directly and utilize their attributes instead of importing the attributes as objects themselves. For instance, in hooks.exceptions, we set sys.excepthook to except_hooks.print_exception. If we were to import excepthook directly from sys, and attempt to set it to except_hooks.print_exception, it would simply be assigning the global variable 'excepthook' within the hooks.exceptions package to that function, and not actually set sys.excepthook to that object.

Other items, which can have ambiguous names, I often import and give them a new name:
[python]from pickle import load as pickle_load
from pickle import dump as pickle_dump[/python]


Also, you have a small mistake in your second code block. You use random directly after importing the objects instead.

[Mahi]

Everything else I pretty much agree on, but this just made me curious

Other items, which can have ambiguous names, I often import and give them a new name:
[python]from pickle import load as pickle_load
from pickle import dump as pickle_dump[/python]

Isn't the whole module's code ran anyways, regardless of how you import it (correct me if I'm wrong)? So why use pickle_dump intead of just importing pickle? I actually find pickle.dump clearer than pickle_dump, since everyone surely knows that dot means it's dump function from pickle module.

[BackRaw]

From the Coding Style thread:

• Do's and Don'ts of Importing (the use of "Good" and "Bad" just show what is/isn't acceptable for "this" project. other people prefer to use the opposite, which is perfectly fine):
  • Never import "all" from a module:[PYTHON]# Bad
    from something import *
    
    # Good
    from something import one_object
    from something import second_object[/PYTHON]
  • For "most" imports, import each object individually, and on a separate line:[PYTHON]# Bad
    from os.path import dirname, join, curdir
    
    # Good
    from os.path import dirname
    from os.path import join
    from os.path import curdir
    
    # "Ok", but use only when necessary
    import os.path
    import sys[/PYTHON]

I am a proponent of absolutely never using 'from x import *' as it is highly implicit and never shows objects actually being defined within the scope of the current module. Again, using 'import x' and directly using x's attributes is fine, but it is preferred for this project itself to use 'from x import y'.

For whatever reason, I typically don't adhere to this when importing from the sys module. Many of the objects in sys are fairly ambiguous and have names that could easily be names of other objects either imported into the current module or defined in the current module.

Some items require you to import the package/module directly and utilize their attributes instead of importing the attributes as objects themselves. For instance, in hooks.exceptions, we set sys.excepthook to except_hooks.print_exception. If we were to import excepthook directly from sys, and attempt to set it to except_hooks.print_exception, it would simply be assigning the global variable 'excepthook' within the hooks.exceptions package to that function, and not actually set sys.excepthook to that object.

Other items, which can have ambiguous names, I often import and give them a new name:
[python]from pickle import load as pickle_load
from pickle import dump as pickle_dump[/python]

Thank you very much!

Also, you have a small mistake in your second code block. You use random directly after importing the objects instead.

Corrected.

[satoon101]

Isn't the whole module's code ran anyways, regardless of how you import it (correct me if I'm wrong)? So why use pickle_dump intead of just importing pickle? I actually find pickle.dump clearer than pickle_dump, since everyone surely knows that dot means it's dump function from pickle module.

Yes, the code in the global scope is executed on import, but that is not the point I was trying to convey. I was simply trying to point out that if an imported object's name is ambiguous, give it a more unique name that tells better what it is or does.

[Mahi]

Isn't the whole module's code ran anyways, regardless of how you import it (correct me if I'm wrong)? So why use pickle_dump intead of just importing pickle? I actually find pickle.dump clearer than pickle_dump, since everyone surely knows that dot means it's dump function from pickle module.

Yes, the code in the global scope is executed on import, but that is not the point I was trying to convey. I was simply trying to point out that if an imported object's name is ambiguous, give it a more unique name that tells better what it is or does.

Oh okay, sorry then