Используете ли вы глобальный оператор в Python?

Я использую «глобальный» в таком контексте:

_cached_result = None
def myComputationallyExpensiveFunction():
    global _cached_result
    if _cached_result:
       return _cached_result

    # ... figure out result

    _cached_result = result
    return result

Я использую «глобальный», потому что это имеет смысл и понятно читателю функции, что происходит. Я также знаю, что есть такой шаблон, который эквивалентен, но создает большую когнитивную нагрузку на читателя:

def myComputationallyExpensiveFunction():
    if myComputationallyExpensiveFunction.cache:
        return myComputationallyExpensiveFunction.cache

    # ... figure out result

    myComputationallyExpensiveFunction.cache = result
    return result
myComputationallyExpensiveFunction.cache = None

У меня никогда не было законного использования этого оператора в каком-либо производственном коде за 3 с лишним года профессионального использования Python и более пяти лет в качестве любителя Python. Любое состояние, которое мне нужно изменить, находится в классах или, если есть какое-то «глобальное» состояние, оно находится в некоторой общей структуре, такой как глобальный кеш.

Я использовал его в ситуациях, когда функция создает или устанавливает переменные, которые будут использоваться глобально. Вот некоторые примеры:

discretes = 0
def use_discretes():
    #this global statement is a message to the parser to refer 
    #to the globally defined identifier "discretes"
    global discretes
    if using_real_hardware():
        discretes = 1
...

or

file1.py:
    def setup():
        global DISP1, DISP2, DISP3
        DISP1 = grab_handle('display_1')
        DISP2 = grab_handle('display_2')
        DISP3 = grab_handle('display_3')
        ...

file2.py:
    import file1

    file1.setup()
    #file1.DISP1 DOES NOT EXIST until after setup() is called.
    file1.DISP1.resolution = 1024, 768

На мой взгляд, как только вы почувствуете необходимость использовать глобальные переменные в коде Python, самое время остановиться и поработать над рефакторингом вашего кода.
Добавление global в код и отсрочка рефакторинга процесс может звучать многообещающе, если ваш крайний срок близок, но, поверьте мне, вы не собираетесь возвращаться к этому и исправлять, если вам действительно не нужно - например, ваш код перестал работать по какой-то странной причине, вам нужно его отладить, вы сталкиваетесь с некоторыми из этих global переменных, и все, что они делают, это все портит.

Так что, честно говоря, даже если это разрешено, я бы старался избегать его использования. Даже если это означает простую сборку классов вокруг вашего фрагмента кода.

Объекты являются предпочтительным способом иметь нелокальное состояние, поэтому глобальное состояние требуется редко. Я не думаю, что будущий модификатор nonlocal также будет широко использоваться, я думаю, что он в основном предназначен для того, чтобы шепелявые перестали жаловаться :-)

Я использую его для глобальных параметров со сценариями командной строки и «optparse»:

мой main() анализирует аргументы и передает их любой функции, выполняющей работу сценария... но записывает предоставленные параметры в глобальный словарь «opts».

Параметры сценария оболочки часто изменяют поведение «листа», и неудобно (и не нужно) пропускать словарь «opts» через каждый список аргументов.

Я избегаю этого, и у нас даже есть правило pylint, которое запрещает это в нашем производственном коде. Я вообще считаю, что его вообще не должно быть.

Редко. Я так и не нашел ему применения вообще.

Это может быть полезно в потоках для совместного использования состояния (с блокирующими механизмами вокруг него).

Тем не менее, я редко, если вообще когда-либо использую его.

Я использовал его в быстрых и грязных одноразовых сценариях для автоматизации некоторых одноразовых задач. Все, что больше этого или что нужно использовать повторно, и я найду более элегантный способ.

Раз или два. Но это всегда было хорошей отправной точкой для рефакторинга.

Если я могу этого избежать, то нет. И, насколько мне известно, всегда есть способ избежать этого. Но я и не утверждаю, что это совершенно бесполезно.