Such nach config.h ähnlicher Funktion

anonym44 · Sonntag 15. November 2015, 08:43

Hallo Freunde,

seit Wochen überlege ich wie ich so etwas wie confih.h in CPP mir Python bewerkstelligen kann.

Beispiel #1:
config.h

Code: Alles auswählen

import sys
sys.path.append("../3party")  #Pfad zu iconv

alle anderen Module m

Code: Alles auswählen

import config
import iconv

Beispiel #2:
Jedes Modul muss bib_p27 einbinden und schreibe daher:
config.py

Code: Alles auswählen


#import bib_p30
import bib_p27

alle module brauchen dann nur noch config importieren

Code: Alles auswählen

import config

#...
#los geht's

Danke

Kebap · Sonntag 15. November 2015, 09:27

Hallo Amerika_befreie_uns

schau dir mal diesen Thread und den Link zum Tutorial an. Ich schätze, __init__.py kann dir helfen: http://www.python-forum.de/viewtopic.ph ... 9&p=287220

anonym44 · Sonntag 15. November 2015, 09:39

Ich habe schon __init__.py ausprobiert.

Wenn ich in __init__.py

Code: Alles auswählen

print("init from...")

schreibe und ich ein module ausführe sollte doch die Nachricht ""init from..." erscheinen oder?

DasIch · Sonntag 15. November 2015, 13:06

Amerika_befreie_uns hat geschrieben:seit Wochen überlege ich wie ich so etwas wie confih.h in CPP mir Python bewerkstelligen kann.

Gar nicht. C++ ist nicht Python und Python ist nicht C++. Es ist keine gute Idee die Konzepte aus C++ einfach blind zu übernehmen. Was du vor hast geht in Python glücklicherweise nicht und ist auch in anderen Sprachen mMn kein guter Stil.

Sirius3 · Sonntag 15. November 2015, 14:46

@Amerika_befreie_uns: kannst Du in Worten erklären, was Du eigentlich erreichen willst, und nicht wie Du Dir die Lösung (config.h) vorstellst. Wenn wir das eigentliche Problem verstehen, ist es viel einfacher, eine saubere Lösung zu finden.

anonym44 · Dienstag 17. November 2015, 09:03

Hallo Freunde,

ich möchte folgendes umsetzen:

ich habe folgende Ordnerstruktur:
Projekt/

Quellcode/
lib/

Um ein Modul aus dem Ordner lib zu laden muss ich im erst

Code: Alles auswählen

import sys
sys.path.append("../lib") # Abhängigkeiten
import dep_mod

schreiben um dep_mod importieren zu können.

Wenn ich so etwas wie ein config-Modul hätte dann muss ich nur einmal die Abhängigkeitsordner angeben und kann dann direkt:
import dep_mod
aufrufen.

Es der lib-Ordner kann sich jeder Zeit ändern, oder es werden welche hinzugefügt.

Daikoku · Dienstag 17. November 2015, 11:57

@Amerika_befreie_uns : Ich habe Dein Problem im Ganzen leider immer noch nicht wirklich verstanden. Sorry habe aber auch erst die zweite Tasse Kaffee.

Was mir auf dem ersten Blick aufgefallen ist:
- Was ist Deine Systemumgebung - Windows ??, Linux ??, Mac ??
- ich würde niemals einfach sys.path.append("../lib") verwenden.
- sys.path hat eine gewisse Struktur und diese würde ich beibehalten und lieber so etwas verwenden:

Code: Alles auswählen

_cmd_folder = os.path.realpath(os.path.join(os.path.dirname(__file__), "../"))

if _cmd_folder not in sys.path:
    sys.path.insert(0, _cmd_folder)

Daikoku · Dienstag 17. November 2015, 12:56

Nachtrag ....
Bei Deiner Struktur und der Schilderung des Problems dürfte es eigentlich keine Probleme beim importieren geben.
Dazu braucht es keine Modifikationen an sys.path. Benutzt Du Die richtige Syntax ?

import lib.<modul_name.py> oder from lib.<modul_name.py> import <wathever>

Eine __init__.py kann auch einfach leer sein. Da muss nicht unbedingt etwas drin stehen. Sie muss halt nur vorhanden sein.
Prüfe bitte Deine Struktur, da scheint irgend etwas nicht in Ordnung zu sein.

BlackJack · Dienstag 17. November 2015, 14:15

@Daikoku: Ich vermute `lib/` ist tatsächlich literal gemeint, also ein Ordner der tatsächlich `lib/` heisst und *in dem* die Bibliothek(en) liegen. Denn in einem Verzeichnis das `lib/` heisst sollte keine `__init__.py` existieren, denn das ist ein wirklich *sehr* schlechter Name für ein Package.

__deets__ · Dienstag 17. November 2015, 15:52

Ich verstehe dein Problem noch nicht ganz. Niemand hindert dich daran, ein config.py oder was auch immer zu machen, um immer die Pfade in lib in sys.path zu hieven. Du kannst das auch smarter machen & statt hart-kodierter Pfade alle Verzeichnisse in lib hinzufuegen.

Allerdings ist in meinen Augen die Loesung eine andere: ich verwende virtalenvs, sowie "richtige" libs, sprich mit eigener setup.py und Versionierung, um so etwas zu machen. Damit kann man jedes Bibliothek einmal in das venv installieren (mittels python setup.py develop sogar nur als "alias", so das alle Aenderungen am Quellcode sichtbar werden). Damit hat dann alles, was ich mit dem python-interpreter des venvs aufrufe, eben diese Bibliotheken zur Verfuegung.

Daikoku · Mittwoch 18. November 2015, 00:00

@BlackJack Danke für Deinen Hinweis, aber im Moment verstehe ich Deinen Hinweis nicht wirklich.

Nachstehend ein Auszug aus meiner Verzeichnisstruktur :

Code: Alles auswählen

C:\Entwicklung
	|+ eigene
	|	|+ app
	|	|	|+ bin
	|	|	|	|+ coding
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ theCodecs.py
	|	|	|	|	|+ theEntities.py	
	|	|	|	|	|+ theEvent.py	
	|	|	|	|
	|	|	|	|+ config
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ preferences.py	
	|	|	|	|
	|	|	|	|+ handlers
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ myFileHandler.py	
	|	|	|	|	|+ mySocketlHandler.py
	|	|	|	|
	|	|	|	|+ reports
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ html.py
	|	|	|	|	|+ typer_reports.py
	|	|	|	|	|+ stats.py
	|	|	|	|	
	|	|	|	|+ tools
	|	|	|	|	|+ __init__.py
	|	|	|	|	|+ dictDifferences.py
	|	|	|	|
	|	|	|	|+ typer.py	
	|	|	|	
	|	|	|+ daten
	|	|	|+ doku 
	|	|	|+ log
	|	|	|+ temp
	|	|	|+ www

Nennen wir die gesamte App der Einfachheit halber Typer, was aber im weiteren eigentlich keine Rolle spielen sollte.
Alle lokalen Module und Pakete befinden sich im Verzeichnis bin.
Alle Verzeichnisse und Module sind echt, also keine Verknüpfungen.
Auch arbeite ich nicht mit einem virtual Environment.
Anstatt Bibliothek(en) benutze ich das Wort Modul(e).
Ich arbeite unter Windows 7 und Python 2.7.10.

Wenn ich die original Dokumentation richtig verstanden habe, ermöglicht mir Python mehrere Module in einem Paket zusammen zu fassen.
Um ein Paket zu erstellen, muss ein Unterordner im Programmverzeichnis erzeugt werden.
Wobei der Name des Ordners dem Namen des Paketes entspricht. Bei Python < 3.3 muss jedes Paket eine __init__.py enthalten.
Ab Version 3.3 wurden Namespace Packages eingeführt, die keine __init__.py enthalten.
Da ich selber mit Python 2.7.10 arbeite, und der ursprüngliche Fragensteller mit __init__.py Dateien arbeitet interessieren mich Namespace Packages an dieser Stelle jetzt einmal nicht.
Das Modul __init__.py kann Code enthalten, muss es aber nicht.
Um die Dinge jetzt nicht zu verkomplizieren gehen wir einmal von einer leeren __init__.py aus.

Mein Programmverzeichnis ist /bin.
Unterhalb von /bin habe ich zum Beispiel ein Verzeichnis /coding mit den Modulen __init__.py, theCodecs.py, theEntities.py und theEvent.py.
Folge ich der Dokumentation, habe ich somit ein Paket mit dem Namen coding erstellt.

Von meinem Hauptmodul /bin/typer.py ausgehend, kann ich die einzelnen Module aus dem Pakte coding ganz einfach importieren.
import coding.theCodecs oder import coding.theCodecs as theCodecs oder from coding.theCodecs import <what_ever>.

Das alles funktioniert hervorragend mit jedem einzelnen Paket.

Dennoch können Probleme auftreten und zwar dann, wenn ich aus dem Modul ./reports/typer_reports.py das Modul ./handlers/myFileHandler.py importieren möchte.
Das Modul typer_reports.py kann handlers/myFileHandler.py nicht finden, was auch nachvollziehbar ist, da das Verzeichnis nicht in sys.path enthalten ist.
Aus diesem Grund führe ich vor dem import folgenden Code aus:

Code: Alles auswählen

_cmd_folder = os.path.realpath(os.path.join(os.path.dirname(__file__), "../"))

if _cmd_folder not in sys.path:
    sys.path.insert(0, _cmd_folder)

und anschließend funktioniert der import.

Ich weiß, das diese keine perfekte Lösung ist, da ich innerhalb der Pakete weitere Pakte anlegen kann und dann auch mein _cmd_folder Objekt Modul für Modul entsprechend anpassen muss.
Wenn ich Module von einem Paket in ein anderes aus welchem Grund auch immer verschiebe, muss ich gleichfalls mein _cmd_folder Objekt ggf. anpassen.
Das sind für mich unnötige Fehlerquellen, aber eine bessere Lösung habe ich zur Zeit leider nicht.

DasIch · Mittwoch 18. November 2015, 00:59

Du solltest *ein* Package für dein Projekt haben unter dem alle anderen Module und Packages zu finden sind.

Darüber hinaus ist deine Verzeichnisstruktur komisch. Du solltest dir mal ein paar Python Projekte anschauen um zu sehen wie so eine Verzeichnisstruktur sinnvollerweise aussieht. Desweiteren gibt es für Python mit PEP 8 einen Style Guide an den man sich halten sollte. Deine Modulnamen verstoßen dagegen und haben darüber hinaus äußerst hässliche und unnötige the und my Präfixe. Die Modulnamen deuten auch darauf hin dass sich darin vielleicht einzelne Klassen verstecken könnten, dies wäre in Python auch schlecht.

anonym44 · Mittwoch 18. November 2015, 01:41

Daikoku hat geschrieben:@BlackJack Danke für Deinen Hinweis, aber im Moment verstehe ich Deinen Hinweis nicht wirklich.

Nachstehend ein Auszug aus meiner Verzeichnisstruktur :
Code: Alles auswählen
C:\Entwicklung
	|+ eigene
	|	|+ app
	|	|	|+ bin
	|	|	|	|+ coding
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ theCodecs.py
	|	|	|	|	|+ theEntities.py	
	|	|	|	|	|+ theEvent.py	
	|	|	|	|
	|	|	|	|+ config
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ preferences.py	
	|	|	|	|
	|	|	|	|+ handlers
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ myFileHandler.py	
	|	|	|	|	|+ mySocketlHandler.py
	|	|	|	|
	|	|	|	|+ reports
	|	|	|	|	|+ __init__.py	
	|	|	|	|	|+ html.py
	|	|	|	|	|+ typer_reports.py
	|	|	|	|	|+ stats.py
	|	|	|	|	
	|	|	|	|+ tools
	|	|	|	|	|+ __init__.py
	|	|	|	|	|+ dictDifferences.py
	|	|	|	|
	|	|	|	|+ typer.py	
	|	|	|	
	|	|	|+ daten
	|	|	|+ doku 
	|	|	|+ log
	|	|	|+ temp
	|	|	|+ www	 
Nennen wir die gesamte App der Einfachheit halber Typer, was aber im weiteren eigentlich keine Rolle spielen sollte.
Alle lokalen Module und Pakete befinden sich im Verzeichnis bin.
Alle Verzeichnisse und Module sind echt, also keine Verknüpfungen.
Auch arbeite ich nicht mit einem virtual Environment.
Anstatt Bibliothek(en) benutze ich das Wort Modul(e).
Ich arbeite unter Windows 7 und Python 2.7.10.

Wenn ich die original Dokumentation richtig verstanden habe, ermöglicht mir Python mehrere Module in einem Paket zusammen zu fassen.
Um ein Paket zu erstellen, muss ein Unterordner im Programmverzeichnis erzeugt werden.
Wobei der Name des Ordners dem Namen des Paketes entspricht. Bei Python < 3.3 muss jedes Paket eine __init__.py enthalten.
Ab Version 3.3 wurden Namespace Packages eingeführt, die keine __init__.py enthalten.
Da ich selber mit Python 2.7.10 arbeite, und der ursprüngliche Fragensteller mit __init__.py Dateien arbeitet interessieren mich Namespace Packages an dieser Stelle jetzt einmal nicht.
Das Modul __init__.py kann Code enthalten, muss es aber nicht.
Um die Dinge jetzt nicht zu verkomplizieren gehen wir einmal von einer leeren __init__.py aus.

Mein Programmverzeichnis ist /bin.
Unterhalb von /bin habe ich zum Beispiel ein Verzeichnis /coding mit den Modulen __init__.py, theCodecs.py, theEntities.py und theEvent.py.
Folge ich der Dokumentation, habe ich somit ein Paket mit dem Namen coding erstellt.

Von meinem Hauptmodul /bin/typer.py ausgehend, kann ich die einzelnen Module aus dem Pakte coding ganz einfach importieren.
import coding.theCodecs oder import coding.theCodecs as theCodecs oder from coding.theCodecs import <what_ever>.

Das alles funktioniert hervorragend mit jedem einzelnen Paket.

Dennoch können Probleme auftreten und zwar dann, wenn ich aus dem Modul ./reports/typer_reports.py das Modul ./handlers/myFileHandler.py importieren möchte.
Das Modul typer_reports.py kann handlers/myFileHandler.py nicht finden, was auch nachvollziehbar ist, da das Verzeichnis nicht in sys.path enthalten ist.
Aus diesem Grund führe ich vor dem import folgenden Code aus:
Code: Alles auswählen
_cmd_folder = os.path.realpath(os.path.join(os.path.dirname(__file__), "../"))

if _cmd_folder not in sys.path:
    sys.path.insert(0, _cmd_folder)
und anschließend funktioniert der import.

Ich weiß, das diese keine perfekte Lösung ist, da ich innerhalb der Pakete weitere Pakte anlegen kann und dann auch mein _cmd_folder Objekt Modul für Modul entsprechend anpassen muss.
Wenn ich Module von einem Paket in ein anderes aus welchem Grund auch immer verschiebe, muss ich gleichfalls mein _cmd_folder Objekt ggf. anpassen.
Das sind für mich unnötige Fehlerquellen, aber eine bessere Lösung habe ich zur Zeit leider nicht.

Gratulation,

wenn du 50 Module hast, musst du den Code 50 Mal schreiben!

Code: Alles auswählen

_cmd_folder = os.path.realpath(os.path.join(os.path.dirname(__file__), "../"))

if _cmd_folder not in sys.path:
    sys.path.insert(0, _cmd_folder)

Das mache ich ja jetzt derzeit, was ich mir erhoffe mir irgendwie ersparen zu koennen, ohne die externen Module installieren zu muessen.

BlackJack · Mittwoch 18. November 2015, 10:06

@Daikoku: Wenn das Programm `typer` das Modul `reports.typer_reports` importieren konnte, dann kann `reports.typer_reports` auch `handlers.myFileHandler` importieren, denn wenn das Package `reports` im Suchpfad für Module liegt, dann liegt auch das `handlers`-Package im Suchpfad. Das liegt ja beides im selben Ordner, darum kann ich Dein Problem an der Stelle nicht nachvollziehen‽

Es gibt also kein literales `lib/`, aber Packages mit Namen wie `config`, `tools`, `handlers`, oder `reports` solltest Du auch nicht haben. Die müssen ja im Modulsuchpfad liegen. Wenn Du jetzt aber irgendwas ausserhalb, zum Beispiel auch aus der Standardbibliothek importierst, was selbst ein Modul Namens `config` oder `tools` hat, das aber nicht absolut importiert, dann findet das nicht sein eigenes Modul sondern Deines als erstes und kann damit dann sehr sicher nichts anfangen. Man sollte im ”globalen” Namensraum für Module und Packages möglichst wenig ”Anfriffsfläche” bieten und alles was an Modulen und Packages zu einem Projekt gehört in *ein* Package packen das einen Namen trägt der wenig Risiko für Kollisionen mit anderen Projekten bietet. Deswegen auch mein ursprünglicher Hinweis das man etwas so supergenerisches wie `lib` nicht zu einem Top-Level-Packagenamen machen sollte.

Man könnte das Package in Deinem Fall beispielsweise `typer` nennen, also `bin/` in `typer/` umbennenen und die `typer.py` in `__init__.py`. Und das Programm dann entweder mit ``python -m typer`` starten oder, was ziemlich üblich ist, ausserhalb ein wirklich sehr kurzes Startskript schreiben.

Daikoku · Freitag 20. November 2015, 00:21

@DasIch : Danke das Du mich auf PEP 8 hingewiesen hast. Ich vergesse hin und wieder darauf zu achten.

Wie von DasIch schon erwähnte, ist meine Verzeichnisstruktur mehr als schlecht und hätte hier dem Grunde nach gar nicht geposted werden dürfen.
Gedanklich war ich bei den Ausführungen von BlackJack zu der __init__.py und habe ohne nachzudenken, einfach eine Verzeichnisstruktur von meiner SSD genommen.
Werde in Zukunft erst Denken und dann senden, damit so ein Unsinn, hier nicht unnötiger Weise berichtigt werden muss.

@BlackJack: Deine letzten Ausführungen teile ich uneingeschränkt. Darüber hinaus befürchte ich, das ich unter dem Namen "lib" etwas völlig anderes verstehe als Du.
Sorry, aber ich bin kein Softwareentwickler, für mich könnte das auch eine Abkürzung für lost in bytes sein.
Für Dich eher nicht, weil Du anscheinend etwas ganz bestimmtes damit assoziierst und diesen Namen hier eher nicht verwenden würdest.

Der Einfachheit halber habe ich, die nicht PEP 8 konformen Verzeichnisse entfernt und die Anmerkungen von BlackJack berücksichtigt :

Code: Alles auswählen

C:\Entwicklung
   |+ eigene
   |   |+ app
   |   |   |+ typer
   |   |   |   |+ config
   |   |   |   |   |+ __init__.py
   |   |   |   |   |+ preferences.py
   |   |   |   |   
   |   |   |   |+ reports
   |   |   |   |   |+ __init__.py
   |   |   |   |   |+ html.py
   |   |   |   |   |+ typer_reports.py
   |   |   |   |   |+ stats.py
   |   |   |   |   
   |   |   |   |+ tools
   |   |   |   |   |+ __init__.py
   |   |   |   |   |+ dict_differences.py
   |   |   |   |
   |   |   |   |+ __init__.py	# vormals typer.py

Selbstverständlich kann das Modul typer_reports.py jetzt das Modul preferences.py importieren. import typer.config.preferences.

Auszug aus sys.path aus der Sicht des Moduls typer_reports.py zum Zeitpunkt des imports:
- C:\Entwicklung\eigene\app
- C:\Entwicklung\eigene\app\typer\reports

Unterhalb von /app kann ich weitere Packages erstellen.

Code: Alles auswählen

C:\Entwicklung
   |+ eigene
   |   |+ app
   |   |   |+ typer
.
.
.
   |   |   |+ whydo
   |   |   |   |+ reports
   |   |   |   |   |+ __init__.py
   |   |   |   |   |+ whydo_reports.py
   |   |   |   |
   |   |   |   |+ __init__.py

Packages können Packages importieren.
Somit funktioniert auch aus typer_reports.py heraus ein import von whydo.reports.annual_reports.
Somit ist ein zentrales config Modul oder eine Bearbeitung der sys.path Liste nicht erforderlich.

@Amerika_befreie_uns
Wenn Du jetzt eine lose Ansammlung von Modulen hast, und keine Package-Struktur erstellen möchtest, findet Python alle Module unterhalb von ./* des jeweils ausführenden Moduls.
Alles was ../ ist, bleibt zunächst einmal unerkannt, weil nicht in sys.path enthalten. Das kann man entsprechend hacken, aber wie bereits geschrieben,
würde ich nicht einfach ein sys.path.append("../whydo") verwenden, da sys.path eine gewisse Struktur hat, und diese würde ich versuchen zu erhalten.
Derartige Hacks gehören für mich jedoch nicht in eine Produktionsumgebung. So etwas benutze ich nur, wenn ich mal eben etwas quick und dirty ausprobieren möchte.

Zurück zu Deinem Problem und Deiner Ordnerstruktur, ungeachtet den Anmerkungen zu den Verzeichnisnamen, sollte so etwas wie:

Code: Alles auswählen

Projekt
   |+ Quellcode
   |    |+ __init__.py
 .
   |+ lib
   |    |+ __init__.py

bei Dir vorhanden sein.

Unterhalb von Quellcode und/oder lib kannst Du weitere Ordner/Verzeichnisse oder Module erstellen.
Jedes Verzeichnis muss dann aber auch eine __init__.py enthalten.
Dann kannst Du auch Verzeichnisübergreifende Packages und/oder einzelne Module importieren.
Zum Beispiel so: import lib.<Verzeichniss>.<modul> oder from lib.<Verzeichniss>.<modul> import <whatever> und musst nicht 50x den gleichen sys.path Hack implementieren.
Denke bitte daran, das auch import lib.<Verzeichniss>.<modul> as <name> funktioniert, wenn Du nicht ständig lib.<Verzeichniss>.<modul>.<funktionsname>() verwenden möchtest.

Schau Dir bitte einmal das Package twisted https://pypi.python.org/pypi/Twisted an.
Dieses Entwicklerteam hält sich strickt an PEP 8 und sonstige Guidlines.
Hier könntest Du einige Anregungen finden, was alles in einer __init__.py stehen könnte und wie eine größere Verzeichnisstruktur aussehen würde.

Anstelle einer print Anweisung, kannst Du auch den import debuggen und siehst dann, step by step, welche Module wie verarbeitet werden.
Eine einfache print Anweisung kann auch mal schnell übersehen werden.

BlackJack · Freitag 20. November 2015, 00:36

@Daikoku: „lib“ ist die gängige Abkürzung für „library“, also Bibliothek, und das ist letztendlich ja jedes Package, ist also ähnlich aussagekräftig als würde man ein Package tatsächlich `package` nennen.

Daikoku · Freitag 20. November 2015, 00:48

@BlackJack: Danke für Deine kurze Erklärung. Vielleicht könntest Du mir noch einmal kurz helfen.
Sorry, aber meine Synapsen finden keinen passenden Link zu den Python-Codebox-Tags.
Wie kann ich die Einfügen. Eckige Klamme auf und dann ...

cofi · Freitag 20. November 2015, 01:32

Es gibt da eine Listbox direkt ueber dem Textbereich in dem "Code auswählen" steht. Da waehlst du einfach Python aus

(Oder was auch immer besser passt).

Daikoku · Freitag 20. November 2015, 03:05

@cofi: Danke, hatte ich mir eigentlich auch genauso gedacht. Intuitive.
In meiner Vorschau steht im Code-Bereich: "Die Vorschau ist nicht verfügbar". Ob das alles so richtig ist ? und was ist mit file=Unbenannt.py?
OK, ich ignoriere das jetzt einmal alles und schicke es ab.

Code: Alles auswählen

# Funktionieren die Python-Codebox-Tags ???
#
print 'Hallo, from the Python-Codebox-Tags'

Daikoku · Freitag 20. November 2015, 03:07

Hat wunderbar funktioniert. Danke an Alle.