Est-ce pythonique d'importer des fonctions internes?

PEP 8 dit:

• Les importations sont toujours placées en haut du fichier, juste après les commentaires et les docstrings du module, et avant les globales et les constantes du module.

À l'occasion, je viole PEP 8. Parfois, j'importe des trucs à l'intérieur de fonctions. En règle générale, je fais cela s'il y a une importation qui n'est utilisée que dans une seule fonction.

Des opinions?

EDIT (la raison pour laquelle j'ai l'impression d'importer des fonctions peut être une bonne idée):

Raison principale: cela peut rendre le code plus clair.

• En regardant le code d'une fonction, je pourrais me demander: "Qu'est-ce qu'une fonction / classe xxx?" (xxx étant utilisé dans la fonction). Si j'ai toutes mes importations en haut du module, je dois y aller pour déterminer ce qu'est xxx. C'est plus un problème lors de l'utilisation from m import xxx. Voir m.xxxdans la fonction m'en dit probablement plus. Selon ce qui mest: S'agit-il d'un module / package de premier niveau bien connu ( import m)? Ou est-ce un sous-module / package ( from a.b.c import m)?
• Dans certains cas, avoir ces informations supplémentaires ("Qu'est-ce que xxx?") À proximité de l'endroit où xxx est utilisé peut rendre la fonction plus facile à comprendre.

À long terme, je pense que vous apprécierez d'avoir la plupart de vos importations en haut du fichier, de cette façon, vous pouvez voir d'un coup d'œil à quel point votre module est compliqué par ce qu'il doit importer.

Si j'ajoute un nouveau code à un fichier existant, je fais généralement l'importation là où c'est nécessaire, puis si le code reste, je rendrai les choses plus permanentes en déplaçant la ligne d'importation en haut du fichier.

Un autre point, je préfère obtenir une ImportErrorexception avant l'exécution de tout code - comme vérification de l'intégrité, c'est donc une autre raison d'importer en haut.

J'utilise pyCheckerpour vérifier les modules inutilisés.

Il y a deux occasions où je viole la PEP 8 à cet égard:

• Importations circulaires: le module A importe le module B, mais quelque chose dans le module B nécessite le module A (bien que ce soit souvent un signe que je dois refactoriser les modules pour éliminer la dépendance circulaire)
• Insérer un point d'arrêt pdb: import pdb; pdb.set_trace()C'est pratique b / c je ne veux pas mettre import pdben haut de chaque module que je pourrais vouloir déboguer, et il est facile de se souvenir de supprimer l'importation lorsque je supprime le point d'arrêt.

En dehors de ces deux cas, c'est une bonne idée de tout mettre en haut. Cela rend les dépendances plus claires.

Voici les quatre cas d'utilisation d'importation que nous utilisons

1. import(et from x import yet import x as y) en haut

2. Choix pour l'importation. Au sommet.

   import settings
   if setting.something:
       import this as foo
   else:
       import that as foo
   

3. Importation conditionnelle. Utilisé avec les bibliothèques JSON, XML et autres. Au sommet.

   try:
       import this as foo
   except ImportError:
       import that as foo
   

4. Importation dynamique. Jusqu'à présent, nous n'avons qu'un seul exemple de cela.

   import settings
   module_stuff = {}
   module= __import__( settings.some_module, module_stuff )
   x = module_stuff['x']
   

   Notez que cette importation dynamique n'apporte pas de code, mais apporte des structures de données complexes écrites en Python. C'est un peu comme une donnée décapée, sauf que nous l'avons décapée à la main.

   C'est aussi, plus ou moins, en haut d'un module

Voici ce que nous faisons pour rendre le code plus clair:

• Gardez les modules courts.

• Si j'ai toutes mes importations en haut du module, je dois aller y chercher pour déterminer ce qu'est un nom. Si le module est court, c'est facile à faire.

• Dans certains cas, avoir ces informations supplémentaires à proximité de l'endroit où un nom est utilisé peut rendre la fonction plus facile à comprendre. Si le module est court, c'est facile à faire.

Une chose à garder à l'esprit: les importations inutiles peuvent entraîner des problèmes de performances. Donc, si c'est une fonction qui sera appelée fréquemment, vous feriez mieux de simplement mettre l'importation en haut. Bien sûr, il s'agit d' une optimisation, donc s'il y a un cas valable à faire pour que l'importation à l'intérieur d'une fonction soit plus claire que l'importation en haut d'un fichier, cela l'emporte sur les performances dans la plupart des cas.

Si vous utilisez IronPython, on me dit qu'il est préférable d'importer des fonctions internes (car la compilation de code dans IronPython peut être lente). Ainsi, vous pourrez peut-être obtenir un moyen d'importer des fonctions internes. Mais à part cela, je dirais que cela ne vaut tout simplement pas la peine de lutter contre les conventions.

En règle générale, je fais cela s'il y a une importation qui n'est utilisée que dans une seule fonction.

Un autre point que je voudrais faire est que cela peut être un problème de maintenance potentiel. Que se passe-t-il si vous ajoutez une fonction qui utilise un module qui était auparavant utilisé par une seule fonction? Allez-vous vous rappeler d'ajouter l'importation en haut du fichier? Ou allez-vous analyser chaque fonction pour les importations?

FWIW, il y a des cas où il est logique d'importer à l'intérieur d'une fonction. Par exemple, si vous souhaitez définir la langue dans cx_Oracle, vous devez définir une _variable d'environnement NLS LANG avant son importation. Ainsi, vous pouvez voir un code comme celui-ci:

import os

oracle = None

def InitializeOracle(lang):
    global oracle
    os.environ['NLS_LANG'] = lang
    import cx_Oracle
    oracle = cx_Oracle

J'ai déjà enfreint cette règle pour les modules qui s'auto-testent. Autrement dit, ils ne sont normalement utilisés que pour le support, mais je définis un principal pour eux afin que si vous les exécutez seuls, vous puissiez tester leurs fonctionnalités. Dans ce cas, j'importe parfois getoptet cmdjuste en général, parce que je veux qu'il soit clair pour quelqu'un qui lit le code que ces modules n'ont rien à voir avec le fonctionnement normal du module et ne sont inclus que pour les tests.

Venant de la question sur le chargement du module deux fois - Pourquoi pas les deux?

Une importation en haut du script indiquera les dépendances et une autre importation dans la fonction rendra cette fonction plus atomique, tout en ne causant apparemment aucun inconvénient en termes de performances, car une importation consécutive est bon marché.

Tant que ce n'est importpas le cas from x import *, vous devriez les mettre en haut. Il ajoute juste un nom à l'espace de noms global, et vous vous en tenez à PEP 8. De plus, si vous en avez besoin plus tard ailleurs, vous n'avez rien à déplacer.

Ce n'est pas grave, mais comme il n'y a presque aucune différence, je suggérerais de faire ce que PEP 8 dit.

Jetez un œil à l'approche alternative utilisée dans sqlalchemy: injection de dépendances:

@util.dependencies("sqlalchemy.orm.query")
def merge_result(query, *args):
    #...
    query.Query(...)

Remarquez comment la bibliothèque importée est déclarée dans un décorateur, et passée en argument à la fonction !

Cette approche rend le code plus propre et fonctionne également 4,5 fois plus rapidement qu'une importinstruction!

Benchmark: https://gist.github.com/kolypto/589e84fbcfb6312532658df2fabdb796

Dans les modules qui sont à la fois des modules «normaux» et qui peuvent être exécutés (c'est-à-dire qui ont une section if __name__ == '__main__':), j'importe généralement des modules qui ne sont utilisés que lors de l'exécution du module dans la section principale.

Exemple:

def really_useful_function(data):
    ...


def main():
    from pathlib import Path
    from argparse import ArgumentParser
    from dataloader import load_data_from_directory

    parser = ArgumentParser()
    parser.add_argument('directory')
    args = parser.parse_args()
    data = load_data_from_directory(Path(args.directory))
    print(really_useful_function(data)


if __name__ == '__main__':
    main()

Il y a un autre cas (probablement "dans le coin") où il peut être bénéfique à l' importintérieur de fonctions rarement utilisées: raccourcir le temps de démarrage.

J'ai frappé ce mur une fois avec un programme plutôt complexe s'exécutant sur un petit serveur IoT acceptant les commandes d'une ligne série et effectuant des opérations, peut-être des opérations très complexes.

Placer des importinstructions en haut des fichiers destinés à traiter toutes les importations avant le démarrage du serveur; depuis la importliste inclus jinja2, lxml, signxmlet d' autres « poids lourds » de (et SoC n'a pas été très puissant) , cela signifiait minutes avant la première instruction a été effectivement exécuté.

OTOH plaçant la plupart des importations dans des fonctions, j'ai pu avoir le serveur "vivant" sur la ligne série en quelques secondes. Bien sûr, lorsque les modules étaient réellement nécessaires, je devais en payer le prix (Remarque: cela peut également être atténué en créant une tâche d'arrière-plan importen temps d'inactivité).