1

I want to build my own package in which I'm using package numpy. For more intuitive example let's consider:

import numpy as np
def my_fun(x, y):
    return np.linspace(x, y)

My question is: Is there any better way to include external packages ? I saw in source code of package numpy that they using exactly same convention i.e. to import packages in the function scripts. Do we have a better way to do that ?
For example to have another .py file only with imported packages

John
  • 1,849
  • 2
  • 13
  • 23
  • Does this answer your question? [Python naming conventions for modules](https://stackoverflow.com/questions/711884/python-naming-conventions-for-modules) – Rene Mar 12 '21 at 12:14
  • This is not exactly about naming but more about layout of files – John Mar 12 '21 at 12:15
  • Hi @John! Please check out my answer and if it's what you were looking for, please, consider accepting it as the correct one – marsolmos Mar 17 '21 at 21:54

1 Answers1

2

According to PEP 8 Style Guide:

Imports should usually be on separate lines

# Correct:
import os
import sys
# Wrong:
import sys, os

It's okay to say this though:

# Correct:
from subprocess import Popen, PIPE

Imports are always put at the top of the file

Just after any module comments and docstrings, and before module globals and constants.

Imports should be grouped in the following order:

  1. Standard library imports.
  2. Related third party imports.
  3. Local application/library specific imports.

You should put a blank line between each group of imports.

Absolute imports are recommended

They are usually more readable and tend to be better behaved (or at least give better error messages) if the import system is incorrectly configured (such as when a directory inside a package ends up on sys.path):

import mypkg.sibling
from mypkg import sibling
from mypkg.sibling import example

However, explicit relative imports are an acceptable alternative to absolute imports, especially when dealing with complex package layouts where using absolute imports would be unnecessarily verbose:

from . import sibling
from .sibling import example

Standard library code should avoid complex package layouts and always use absolute imports.

Implicit relative imports should never be used and have been removed in Python 3.

When importing a class from a class-containing module.

It's usually okay to spell this:

from myclass import MyClass
from foo.bar.yourclass import YourClass

If this spelling causes local name clashes, then spell them explicitly:

import myclass
import foo.bar.yourclass

and use "myclass.MyClass" and "foo.bar.yourclass.YourClass".

Wildcard imports (from import *) should be avoided.

They make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn't known in advance).

When republishing names this way, the guidelines below regarding public and internal interfaces still apply.

More info here: https://www.python.org/dev/peps/pep-0008/#imports

marsolmos
  • 748
  • 9
  • 24