Modulübergreifende Globale Variablen und Klassenvariablen

[Leonidas]

Happy programmglobales Debugging. Das ist ja noch toller als modulglobales Debugging, weil die Werte von überall geändert werden können.

[Tristan]

Klar sollten von einer Software-Design Perspektive betrachtet möglichst keine oder nur sehr wenige Variablen global sein. In manchen Situationen erweisst es sich aber als extrem nützlich. So gibt es manchmal z.B. allgemeine Objekte die fast überall gebraucht werden und wo der Komfort an einer Stelle auf diese zugreifen zu können, gegenüber dem "Verkapselungs-Ideal" überwiegt.

Globale Variablen, spährlich verwendet, entsprechen vom Nutzen her in etwa dem "Singleton" design-pattern, das anders in Python nicht umzusetzen ist. Vorallem wenn solche globale Variablen nur zum lese-Zugriff verwendet werden, ist der Gebrauch in bestimmten Situationen durchaus berechtigt, denk ich.

[Zap]

Ich kann mich Tristan nur anschließen. Ich habe eine solche Methode ebenfalls angewendet in welcher Initialisierte Werte Projektweit zur verfügung gestellt wurden.
Allein der Gedanke das über irgendwelche externen Files zu händeln missfällt mir.
Die einzige Gefahr die man dabei immer im Auge behalten muss, ist (wie Gerold schon sagte), dass man das Modul immer auf dem gleichen Wege importieren muss.

Mal ne andere Frage: Wenn man das über Dateien machen würde kann man es ja schlecht über Tempfiles machen, da die anderen Module ja nicht wissen wie diese heissen. Macht man es über feste Namen gibts verherende Konflikte wenn man zwei Instanzen einer Applikation hat.
Wie könnte man diese Probleme geschickt lösen?

[gerold]

Hallo!

Ich möchte allgemein darauf hinweisen, dass dieser Thread noch aus dem Jahr 2006 stammt. Und sich inzwischen alle Beteiligten viel besser mit Python auskennen, als das vor zwei Jahren der Fall war.

mfg
Gerold

[Zap]

Ich möchte allgemein darauf hinweisen, dass dieser Thread noch aus dem Jahr 2006 stammt.

Danke für den Hinweis, das ist mir voll nicht aufgefallen.
Und ich steig auch noch mit in die Diskusion ein

[Jan.O]

Hallo!

Ich möchte allgemein darauf hinweisen, dass dieser Thread noch aus dem Jahr 2006 stammt. Und sich inzwischen alle Beteiligten viel besser mit Python auskennen, als das vor zwei Jahren der Fall war.

mfg
Gerold

Hi Gerold,

Wolltest du damit vor 1,25 Jahren sagen, dass diese Methode Variablen zu globalisieren nach der Python-Philosophie nicht verwerflich ist?

Ich habe nämlich gerade genau das selbe problem, welches in diesem Thread beschrieben wurde, mit einem Web Framework. Ich muss die threadgebundene DB-Verbindung in allen Klassen verwenden können, die teilweise auch in Module ausgelagert sind.

[DasIch]

Das hat nichts mit Python zu tun. Dieses Design ist ein Alptraum. Eines der wichtigsten Dinge um sauberen Code zu erzeugen ist Seiteneffekte zu vermeiden und nicht noch zu forcieren.

[gerold]

Wolltest du damit vor 1,25 Jahren sagen, dass diese Methode Variablen zu globalisieren nach der Python-Philosophie nicht verwerflich ist?

Hallo Jan.O!

Ich weiß nicht, was du mich damit fragen möchtest. Aber das was ich damals sagen wollte ist, dass es bessere Möglichkeiten gibt, eine Variable "global" für alle in das Programm eingebundenen Module zu halten.

Da ich mich mit SQLAlchemy nicht auskenne, kann ich dir bei deinem Problem nicht helfen. Aber wenn du eine Variable global für alle Programmmodule halten willst, dann musst du diese Variable nur in ein Modul schreiben und dieses Modul in jedem anderen Modul importieren, in welchem du diese Variable brauchst.

globalvars.py:

Code: Alles auswählen

#!/usr/bin/env python
#coding: utf-8
# globalvars.py

global_value_a = 10
global_value_b = 20

module1.py:

Code: Alles auswählen

#!/usr/bin/env python
#coding: utf-8
# module1.py

import globalvars


def print_globalvars():
    print globalvars.global_value_a
    print globalvars.global_value_b
    globalvars.global_value_a = 11
    globalvars.global_value_b = 21

module2.py:

Code: Alles auswählen

#!/usr/bin/env python
#coding: utf-8
# module2.py

import globalvars


def print_globalvars():
    print globalvars.global_value_a
    print globalvars.global_value_b
    globalvars.global_value_a = 12
    globalvars.global_value_b = 22

myprogram.py:

Code: Alles auswählen

#!/usr/bin/env python
#coding: utf-8
# my_program.py

import globalvars
import module1
import module2


def main():
    module1.print_globalvars()
    module2.print_globalvars()

    print globalvars.global_value_a
    print globalvars.global_value_b


if __name__ == "__main__":
    main()

Das löst aber nicht dein Threading-Problem. Außerdem ist es ratsamer, alle benötigten Objekte beim Aufruf einer Funktion an diese zu übergeben -- und nicht irgendwoher von einem globalen Variablen-Modul zu holen.

Wenn ich von mehreren Threads aus Zugriff auf eine Datenbank brauche, dann bekommt jeder Thread eine eigene Connection. Fertig Aus! Und die Sache ist gegessen. Wie das bei SQLAlchemy läuft, weiß ich nicht.

mfg
Gerold

[Ghostfighter6]

Moin,
aber der sinnvollste Beitrag war von Tristan aus 2008
Und der hat mir sehr gut geholfen ... die Kommentare, dass globale Variablen nicht verwendet werden sollen ist zwar nett, aber nicht hilfreich

[Dennis89]

Naja, warte mal bis du ein etwas aufwendigeres Programm schreiben musst, dann siehst du, dass das sehr hilfreich ist.

[__blackjack__]

@Ghostfighter6: Doch das ist hilfreich Fehler zu vermeiden und unverständliche und damit unwartbare Programme zu schreiben.

[Ghostfighter6]

@Dennis89 :
Keine Ahnung, ob ca. 10k Zeilen mit Zugriffen auf 2Server, Testcase-Erstellung, automatisches Nachflashen vom Steuergerät, automatisches Testen und Auswerten des Testreports und Upload der Testergebnisse auf den Server aufwendig ist.
Ich muss teilweise bis 20 Parameter in die Funktionen übergeben, da ich das nicht im OOP machen will - bin da halt ned so fit.
Und eine Firma gibt dir ned die nötige Zeit, um erstmal in Ruhe 6 oder mehr Monate mit dem Selbststudium zu verbringen und die saubere Programmierung zu erlernen.
Die beauftragen einen Scrum-Master der dich jeden Tag triezt und fragt wie lange du gearbeitet hast, was du gemacht hast, wie lange du noch brauchst und ob 13 Storypoints für die Aufgabe nicht zu viel sind.
Die wollen übermorgen eine fertige Lösung haben ... die natürlich 100% Testcoverage hat.
Vor Jahrzehnten konnte man sich mal in Ruhe einarbeiten und hat sogar noch Kurse dafür bekommen ... alles schon lange gestrichen ... darum arbeiten bei uns nur noch preiswerte Inder

[__blackjack__]

@Ghostfighter6: Also ist das kein Problem das man mit globalen Variablen löst sondern eines wo man Einzelwerte sinnvoll zu Objekten zusammenfassen sollte. Was an sich erst mal nicht einmal OOP ist, denn auch in prozeduraler oder funktionaler Programmierung hat man Verbunddatentypen. Also da wo man in C `struct` oder in Pascal RECORD oder in strukturierten BASIC-Dialekten TYPE verwenden würde. Dafür eine Klasse zu verwenden ist ja noch nicht OOP, aber in Python der Weg so etwas zu handhaben.

[Kebap]

Huch, wieso flammt denn hier plötzlich ein 15 Jahre alter Thread auf?

[__blackjack__]

@Kebap: Wieso nicht? Globale Variablen sind zeitlos und im Grunde ja sogar programmiersprachenübergreifend.