Wie schlecht sind Schattennamen in äußeren Bereichen definiert?

Ich bin gerade zu Pycharm gewechselt und freue mich sehr über alle Warnungen und Hinweise, die es mir gibt, um meinen Code zu verbessern. Außer diesem, den ich nicht verstehe:

This inspection detects shadowing names defined in outer scopes.

Ich weiß, dass es eine schlechte Praxis ist, auf Variablen vom äußeren Bereich aus zuzugreifen, aber was ist das Problem beim Abschatten des äußeren Bereichs?

Hier ist ein Beispiel, in dem Pycharm mir die Warnmeldung gibt:

data = [4, 5, 6]

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

print_data(data)

Keine große Sache in Ihrem obigen Snippet, aber stellen Sie sich eine Funktion mit ein paar weiteren Argumenten und einigen weiteren Codezeilen vor. Dann beschließen Sie, Ihr dataArgument umzubenennen, yaddaaber eine der Stellen zu verpassen, an denen es im Funktionskörper verwendet wird ... dataBezieht sich nun auf das Globale, und Sie beginnen, sich seltsam zu verhalten - wo Sie ein viel offensichtlicheres hätten, NameErrorwenn Sie es nicht getan hätten einen globalen Namen haben data.

Denken Sie auch daran, dass in Python alles ein Objekt ist (einschließlich Module, Klassen und Funktionen), sodass es keine eindeutigen Namespaces für Funktionen, Module oder Klassen gibt. Ein weiteres Szenario besteht darin, dass Sie die Funktion foooben in Ihrem Modul importieren und irgendwo in Ihrem Funktionskörper verwenden. Dann fügen Sie Ihrer Funktion ein neues Argument hinzu und nennen es - Pech - foo.

Schließlich befinden sich integrierte Funktionen und Typen ebenfalls im selben Namespace und können auf dieselbe Weise schattiert werden.

Nichts davon ist ein großes Problem, wenn Sie kurze Funktionen, eine gute Benennung und eine anständige, uneinheitliche Abdeckung haben, aber manchmal müssen Sie weniger als perfekten Code pflegen, und wenn Sie vor solchen möglichen Problemen gewarnt werden, kann dies hilfreich sein.

Die derzeit am besten bewertete und akzeptierte Antwort und die meisten Antworten hier verfehlen den Punkt.

Es spielt keine Rolle, wie lange Ihre Funktion dauert oder wie Sie Ihre Variable beschreibend benennen (um hoffentlich die Wahrscheinlichkeit einer möglichen Namenskollision zu minimieren).

Die Tatsache, dass die lokale Variable oder der Parameter Ihrer Funktion zufällig einen Namen im globalen Bereich gemeinsam hat, ist völlig irrelevant. Unabhängig davon, wie sorgfältig Sie den Namen Ihrer lokalen Variablen auswählen, kann Ihre Funktion niemals vorhersehen, ob mein cooler Name in yaddaZukunft auch als globale Variable verwendet wird. Die Lösung? Mach dir darüber einfach keine Sorgen! Die richtige Einstellung besteht darin, Ihre Funktion so zu gestalten, dass Eingaben von und nur von ihren Parametern in der Signatur verwendet werden. Auf diese Weise müssen Sie sich nicht darum kümmern, was im globalen Bereich liegt (oder sein wird), und dann wird das Abschatten überhaupt kein Problem.

Mit anderen Worten, das Shadowing-Problem ist nur dann von Bedeutung, wenn Ihre Funktion dieselbe lokale Variable UND die globale Variable verwenden muss. Aber Sie sollten ein solches Design in erster Linie vermeiden. Der OP-Code hat KEIN solches Designproblem. Es ist nur so, dass PyCharm nicht klug genug ist und für alle Fälle eine Warnung ausgibt. Um PyCharm glücklich zu machen und unseren Code sauber zu machen, wird diese Lösung aus der Antwort von Silyevsk zitiert , um die globale Variable vollständig zu entfernen.

def print_data(data):
    print data

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

main()

Dies ist der richtige Weg, um dieses Problem zu "lösen", indem Sie Ihr globales Problem beheben / entfernen und Ihre aktuelle lokale Funktion nicht anpassen.

In einigen Fällen kann eine gute Problemumgehung darin bestehen, den vars + -Code in eine andere Funktion zu verschieben:

def print_data(data):
    print data

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

main()

Es kommt darauf an, wie lange die Funktion dauert. Je länger die Funktion ist, desto größer ist die Chance, dass jemand, der sie in Zukunft modifiziert, schreibt data, dass dies das Globale bedeutet. Tatsächlich bedeutet es das Lokale, aber weil die Funktion so lang ist, ist es für sie nicht offensichtlich, dass es ein Lokales mit diesem Namen gibt.

Für Ihre Beispielfunktion denke ich, dass das Abschatten des Globalen überhaupt nicht schlecht ist.

Mach das:

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)

Ich sehe gerne ein grünes Häkchen in der oberen rechten Ecke in Pycharm. Ich füge die Variablennamen mit einem Unterstrich hinzu, um diese Warnung zu löschen, damit ich mich auf die wichtigen Warnungen konzentrieren kann.

data = [4, 5, 6]

def print_data(data_): 
    print(data_)

print_data(data)

Es sieht aus wie es 100% pytest Code-Muster

sehen:

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

Ich hatte das gleiche Problem mit, deshalb habe ich diesen Beitrag gefunden;)

# ./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

Und es wird mit warnen This inspection detects shadowing names defined in outer scopes.

Um dies zu beheben, bewegen Sie einfach Ihr twitterGerät 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_

Und entfernen Sie das twitterGerät wie 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

Dies wird QA, Pycharm und alle glücklich machen