Quanto sono definiti i nomi shadowing negli ambiti esterni?

Sono appena passato a Pycharm e sono molto contento di tutti gli avvisi e i suggerimenti che mi fornisce per migliorare il mio codice. Tranne questo, che non capisco:

This inspection detects shadowing names defined in outer scopes.

So che è una cattiva pratica accedere alla variabile dall'ambito esterno ma qual è il problema con l'ombra dell'ambito esterno?

Ecco un esempio, in cui Pycharm mi dà il messaggio di avviso:

data = [4, 5, 6]

def print_data(data): # <-- Warning: "Shadows 'data' from outer scope
    print data

print_data(data)

Non è un grosso problema nel tuo frammento di cui sopra, ma immagina una funzione con qualche argomento in più e qualche altra riga di codice. Quindi decidi di rinominare il tuo dataargomento come yaddama perdi uno dei luoghi in cui viene utilizzato nel corpo della funzione ... Ora si datariferisce al globale e inizi ad avere comportamenti strani - dove avresti un aspetto molto più ovvio NameErrorse non lo facessi avere un nome globale data.

Ricorda inoltre che in Python tutto è un oggetto (inclusi moduli, classi e funzioni), quindi non esistono spazi dei nomi distinti per funzioni, moduli o classi. Un altro scenario è che si importa la funzione foonella parte superiore del modulo e la si utilizza da qualche parte nel corpo della funzione. Quindi aggiungi un nuovo argomento alla tua funzione e lo chiami - sfortuna - foo.

Infine, anche le funzioni e i tipi incorporati vivono nello stesso spazio dei nomi e possono essere ombreggiati allo stesso modo.

Niente di tutto questo è un grosso problema se si dispone di funzioni brevi, una buona denominazione e una copertura discreta e discreta, ma bene, a volte è necessario mantenere un codice non perfetto ed essere avvertiti di tali possibili problemi potrebbe essere d'aiuto.

La risposta attualmente più votata e accettata e la maggior parte delle risposte qui mancano il punto.

Non importa quanto sia lunga la tua funzione o come dai nomi descrittivi alla tua variabile (per ridurre al minimo la possibilità di potenziali collisioni di nomi).

Il fatto che la variabile locale della sua funzione o il suo parametro capiti di condividere un nome nell'ambito globale è completamente irrilevante. E infatti, non importa con quale cura scegli il nome della tua variabile locale, la tua funzione non potrà mai prevedere "se il mio bel nome yaddaverrà usato anche come variabile globale in futuro?". La soluzione? Semplicemente non ti preoccupare di questo! La mentalità corretta è progettare la propria funzione in modo da consumare input da e solo dai suoi parametri in firma , in questo modo non è necessario preoccuparsi di ciò che è (o sarà) nell'ambito globale, e quindi l'ombreggiatura non diventa affatto un problema.

In altre parole, il problema dell'ombreggiatura è importante solo quando la tua funzione deve utilizzare la stessa variabile locale E la variabile globale. Ma dovresti evitare tale design in primo luogo. Il codice dell'OP NON presenta davvero questo problema di progettazione. È solo che PyCharm non è abbastanza intelligente e dà un avvertimento per ogni evenienza. Quindi, solo per rendere felice PyCharm e anche per rendere pulito il nostro codice, vedere questa soluzione citando la risposta di silyevsk per rimuovere completamente la variabile globale.

def print_data(data):
    print data

def main():
    data = [4, 5, 6]
    print_data(data)

main()

Questo è il modo corretto di "risolvere" questo problema, riparando / rimuovendo la tua cosa globale, non regolando la tua attuale funzione locale.

Una buona soluzione in alcuni casi potrebbe essere quella di spostare il codice + var su un'altra funzione:

def print_data(data):
    print data

def main():
    data = [4, 5, 6]
    print_data(data)

main()

Dipende da quanto tempo è la funzione. Più lunga è la funzione, maggiori sono le possibilità che qualcuno la modifichi in futuro scriverà datapensando che significhi il globale. In realtà significa locale, ma poiché la funzione è così lunga non è ovvio per loro che esiste un locale con quel nome.

Per la tua funzione di esempio, penso che l'ombra del globale non sia affatto male.

Fai questo:

data = [4, 5, 6]

def print_data():
    global data
    print(data)

print_data()

data = [4, 5, 6] #your global variable

def print_data(data): # <-- Pass in a parameter called "data"
    print data  # <-- Note: You can access global variable inside your function, BUT for now, which is which? the parameter or the global variable? Confused, huh?

print_data(data)

Mi piace vedere un segno di spunta verde nell'angolo in alto a destra in Pycharm. Aggiungo i nomi delle variabili con un carattere di sottolineatura solo per cancellare questo avviso in modo da poter concentrarmi sugli avvisi importanti.

data = [4, 5, 6]

def print_data(data_): 
    print(data_)

print_data(data)

Sembra che sia un modello di codice pytest al 100%

vedere:

https://docs.pytest.org/en/latest/fixture.html#conftest-py-sharing-fixture-functions

Ho avuto lo stesso problema, ecco perché ho trovato questo post;)

# ./tests/test_twitter1.py
import os
import pytest

from mylib import db
# ...

@pytest.fixture
def twitter():
    twitter_ = db.Twitter()
    twitter_._debug = True
    return twitter_

@pytest.mark.parametrize("query,expected", [
    ("BANCO PROVINCIAL", 8),
    ("name", 6),
    ("castlabs", 42),
])
def test_search(twitter: db.Twitter, query: str, expected: int):

    for query in queries:
        res = twitter.search(query)
        print(res)
        assert res

E lo avvertirà This inspection detects shadowing names defined in outer scopes.

Per risolvere il problema basta spostare il twitterdispositivo in./tests/conftest.py

# ./tests/conftest.py
import pytest

from syntropy import db


@pytest.fixture
def twitter():
    twitter_ = db.Twitter()
    twitter_._debug = True
    return twitter_

E rimuovi il twitterdispositivo come in./tests/test_twitter2.py

# ./tests/test_twitter2.py
import os
import pytest

from mylib import db
# ...

@pytest.mark.parametrize("query,expected", [
    ("BANCO PROVINCIAL", 8),
    ("name", 6),
    ("castlabs", 42),
])
def test_search(twitter: db.Twitter, query: str, expected: int):

    for query in queries:
        res = twitter.search(query)
        print(res)
        assert res

Questo renderà felici QA, Pycharm e tutti