Mailman 3 September 2011 - python-de

Re: [Python-de] Python 2.7: sys.path vs. PYTHONPATH
by Ole Streicher Sept. 18, 2011

Sept. 18, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Dann hast Du bei 2.6 anders installiert. Kann es sein, dass Du unter 2.6 > setuptools/ditstribute nicht installiert hattest, als Du das andere > installiert hast? Keine Ahnung. Ich administriere den Rechner nicht selbst. Er wurde nur irgendwann upgedatet (auf openSUSE 11.4), allerdings aller Wahrscheinlichkeit ohne irgendwelche lokalen besonderheiten. > Wenn Du sagst, bei 2.6 ging es, bei 2.7 nicht, dann prüfe bitte, ob alle > Deinen Parameter wirklich unverändert sind. Oder noch besser: Mache einen > erneuten Test mit 2.6. Das wäre mit einem Downgrade verbunden und ist daher leider nicht mehr möglich. >> OK, das erklärt einiges. Das heißt (ich kann es gerade nicht testen), es >> sollte reichen, so etwas zu schreiben? > Nein, genügt nicht. Siehe `pydoc site`. import site site.addsitedir('/mylocal/python/lib64/python2.7/site-packages/') so etwas? >> beginnt und unmittelbar aufgerufen wird. Ich habe daher keinen Zugriff >> auf das Environment des Nutzers. > Häh? Entweder, Du bis für die Installation zuständig, dann hast Du Zugriff auf > das Environment des Anwenders. Bin ich nicht, und ich habe auch keinen Zugriff. > Oder Du hast keinen Zugriff auf das Environment des Anwenders, dann > bist Du auch nicht dafür Verantwortlich, dem Anwender eine > funktionsfähige Umgebung zu schaffen. Die Umgebung ist ja funktionsfähig. Ich möchte jetzt lediglich das Script so anpassen, dass es in dieser läuft. Wenn ich dazu private Pakete installiere, dann sollte mein Script diese natürlich auch finden, ohne dass der Anwender da noch irgendwas macht. >> Ich dachte auch immer, dass genau dafür der sys.path vorgesehen ist >> und PYTHONPATH nur dazu dient, den nochmal von außen zu setzen? > > Genau umgekehrt: PYTHONPATH ist der primäre Weg, den Modul-Suchpfad zu > setzen. Denn der ist immer abhängig von der Betriebssystem-Umgebung (wo ist > das Zeug installiert). Damit ist es Aufgabe des Betriebssystems, das der > Anwendung mitzuteilen. Wenn ein Programm eigene Pfade verwendet, dann ist es sinnvoll, diese im Programm selbst zu vermerken -- insbesondere wenn es ein Programm ist, welches für ein spezifisches Problem geschrieben ist (und nach einem Jahr weggeworfen wird). "Das Betriebssystem" weiß doch schlielich gar nicht, wo ich die zusätzlichen Pakete installiere -- aber ich weiß es, und ich sollte meinem Programm dann auch sagen können, wo das ist. >>> Oder verwende virtualenv. >> Ist zumindest nicht unter docs.python.org zu finden. > http://lmgtfy.com/?q=python+virtualenv Das ist mir schon klar. Was ich damit sagen wollte: ich möchte nicht ein spezielles Zusatzpaket installieren, wenn ich die Aufgabe auch schon mit den "Batteries included" lösen kann. Ole

1 0

Re: [Python-de] Python 2.7: sys.path vs. PYTHONPATH
by Ole Streicher Sept. 18, 2011

Sept. 18, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Am 16.09.2011 10:26, schrieb Ole Streicher: >> Unter 2.6 hatte das noch so funktioniert. Was hat sich da verändert? > Sicher, dass das unter 2.6 funktioniert hat? Ja. Unter 2.6 war die Verzeichnisstruktur unter /mylocal/python/lib64/python2.7/site-packages/ folgende: pyfits/ otherpkg/ usw. Jetzt ist sie distribute-0.6.19-py2.7.egg/distribute/ pyfits-3.0-py2.7-linux-x86_64.egg/pyfits/ otherpkg-0.3.3-py2.7.egg/otherpkg/ usw. > Die .pth-Files werden beim Starten von Python vom Modul `site` > abgearbeitet. Also muss das Verzeichnis in PYTHONPATH sein, wenn Du dort > .pth-Dateien verwenden möchtest. OK, das erklärt einiges. Das heißt (ich kann es gerade nicht testen), es sollte reichen, so etwas zu schreiben? ----------------------8<------------------------------------------- import sys sys.path.append('/mylocal/python/lib64/python2.7/site-packages/') import site import pyfits ----------------------8<------------------------------------------- > M.E. ergibt die Installationsmethode, die Du verwendest, so keinen > Sinn. Denn offensichtlich willst Du "site-packages" um Deinen Pfad > erweitern. Mir ist das nicht ganz verständlich: ich hatte doch beim Installieren "--prefix=/mylocal/python" angegeben; warum wird da jetzt zusätzlich ein Verzeichnis "pyfits-3.0-py2.7-linux-x86_64.egg/" eingefügt? > Dann mach es aber doch richtig und setzte PYTHONPATH. Das Problem hier ist, dass es ein Anwenderprogramm gibt, welches mit #!/usr/bin/env python import sys sys.path.append('/mylocal/python/lib64/python2.7/site-packages/') import pyfits beginnt und unmittelbar aufgerufen wird. Ich habe daher keinen Zugriff auf das Environment des Nutzers. Ich dachte auch immer, dass genau dafür der sys.path vorgesehen ist und PYTHONPATH nur dazu dient, den nochmal von außen zu setzen? > Oder verwende virtualenv. Ist zumindest nicht unter docs.python.org zu finden. Viele Grüße Ole

2 1

Python 2.7: sys.path vs. PYTHONPATH
by Ole Streicher Sept. 18, 2011

Sept. 18, 2011

Hallo, ich habe gerade ein eigenartiges Problem nach dem Übergang von Python 2.6 auf 2.7. Einige Pakete werden bei mir lokal installiert, z.B. pyfits, mittels setuptools $ export PYTHONPATH=/mylocal/python/lib64/python2.7/site-packages/ $ python setup.py install --prefix=/mylocal/python $ ls -l $PATHONPATH drwxr-xr-x 4 oles ata 4096 Sep 16 09:52 distribute-0.6.19-py2.7.egg -rw-r--r-- 1 oles ata 286 Sep 16 10:16 easy-install.pth drwxr-xr-x 4 oles ata 34 Sep 16 09:52 pyfits-3.0-py2.7-linux-x86_64.egg -rw-r--r-- 1 oles ata 30 Sep 16 09:52 setuptools.pth -rw-r--r-- 1 oles ata 2362 Sep 16 09:52 site.py -rw-r--r-- 1 oles ata 1757 Sep 16 09:52 site.pyc $ Den Pfad möchte ich jetzt in einem Script verwenden: -----------8<----------------- #!/usr/bin/env python import sys sys.path.append('/mylocal/python/lib64/python2.7/site-packages/') import pyfits print pyfits.__version__ -----------8<----------------- $ unset PYTHONPATH $ python test.py Traceback (most recent call last): File "test.py", line 4, in <module> import pyfits ImportError: No module named pyfits $ Unter 2.6 hatte das noch so funktioniert. Was hat sich da verändert? Viele Grüße Ole

2 1

ConfigParser: Werte aus allen Sections in Interpolation benutzen
by Florian Lindner Sept. 15, 2011

Sept. 15, 2011

Hallo! im ConfigParser (http://docs.python.org/library/configparser.html) kann man ja per "%{spam}s" einen Eintrag spam aus der gleichen Section oder der Default- Section referenzieren. Nun hätte ich das gerne so, dass man so nicht nur Werte aus der gleichen oder der Default-Section benutzen kann, sondern auch aus allen anderen Sections. - Seht ihr da ein grundsätzliches Problem (nicht bei der Implementierung)? - Gibt es einen vorgesehen Punkt in die Interpolation einzugreifen? Ein von ConfigParser abgeleitetete Klasse habe ich eh schon in Benutzung. Nun ist (section, key) eindeutig, leider nicht (key) alleine. Den Identifier müsste ich also aus section und key bilden. Wie mache ich dies am besten, um section und key auch später wieder auseinander zu bekommen: - afaik dürften Punkte sowohl in der Section also auch im Key vorkommen: Aus section + "." + key ist also nicht mehr zu ersehen was was ist. - Wie könnte das sonst funktionieren? Grüße und Danke für alle Ideen, Florian

1 0

Re: [Python-de] Globaler "prefix" o.ae.
by Thomas 'PointedEars' Lahn Sept. 13, 2011

Sept. 13, 2011

Dinu Gherman wrote: > Daher würde ich zumindest es gerne sehen, wenn diese Geschichte > an einem anderen Ort (vielleicht auf einer Debian-Liste?) ausge- > tragen würde, Du liest hier noch nicht lange mit, oder? > und, sofern eine Lösung existiert, diese dann hier bekannt gemacht würde. Soifz. [psf 10.1] Eine mögliche Lösung habe ich doch schon erklärt. Für diejenigen, denen das jetzt immer noch nicht klar ist: *Wenn* man den Originalquelltext von Python-Paketen nicht ändern kann oder will, aber *trotzdem* Namenskollisionen mit bestehenden Paketen vermeiden will, muss man eben ein neues Python-Paket schnüren, in das man die vorhandenen Python-Pakete einpackt (hier: mypackage). Dann *muss* man den Suchpfad geeignet anpassen. Eine Ansatzpunkt dafür ist die PYTHONPATH-Umgebungsvariable (diese kann bei der Debian- Paketinstallation auch *systemweit* automatisch angepasst werden), ein anderer ist sys.path (welches den PYTHONPATH sowie Default-Pfade beinhaltet). Das sieht z. B. folgendermassen aus: -[mypackage/__init__.py]---------------------------------------------- import sys import os def _init(): my_path = os.path.dirname(__file__) if not my_path in sys.path: sys.path.insert(1, my_path) _init() del _init -[mypackage/database/ps2/Database/database.py]------------------------ from common.config.Profile import profiles def foo(): profiles.bar() -[mypackage/common/config/Profile/profiles.py]------------------------ def bar(): print 42 -[test.py]------------------------------------------------------------ import mypackage from mypackage.database.ps2.Database import database as mydatabase #from otherpackage.database import database mydatabase.foo() #database.bla() ---------------------------------------------------------------------- Wie man sieht, kann der Originalquelltext hier unverändert bleiben; nur die __init__.py des äusseren Python-Pakets muss man hinzufügen, und dann muss man das äussere Python-Paket explizit importieren (da dieses dann den Suchpfad um seinen Verzeichnispfad ergänzt). Das äussere Paket muss sich natürlich selbst im Suchpfad befinden. Diese Lösung ist natürlich nicht besonders schön; besser wäre sauberer Quelltext im Originalpaket. Aber es funktioniert – $ PYTHONPATH=../tmp python test.py 42 –, und der Änderungs- und Dokumentationsaufwand ist minimal. Vermutlich gibt es auch noch bessere Hacks, die Regeln für das Finden des Moduls bei der import-Anweisung sind ja recht komplex (RTFM). In jedem Fall wurde bereits von anderer Seite korrekt darauf hingewiesen, dass ein Python-Paket mit unsauberer Struktur allenfalls im privaten Debian- Repository aufgenommen werden wird. HTH -- PointedEars Please do not Cc: me. / Bitte keine Kopien per E-Mail.

4 7

Re: [Python-de] Globaler "prefix" o.ae.
by Ole Streicher Sept. 13, 2011

Sept. 13, 2011

Marek Kubica <marek(a)xivilization.net> writes: > Ist dann auch die Frage, ob es ein Debian-Package braucht, wenn die > Software möglicherweise Probleme mit anderer Software verursacht. Das Packen in ein Debianpaket hat den Vorteil der einfachen und automatischen Administration -- selbst wenn man sein eigenes Package-Repository pflegt. Einmal installiert, braucht sich der User um nichts mehr kümmern. Perfekt für normale Endanwender. Es in die offizielle Debian-Release einfließen zu lassen ist da eher ein Add-On, was neben den hier erwähnten noch zu einer ganzen Reihe anderer Probleme führt. Viele Grüße Ole

3 2

Re: [Python-de] Mailinglist-Gateway
by Marek Kubica Sept. 13, 2011

Sept. 13, 2011

On Mon, 12 Sep 2011 15:52:04 +0000 (UTC) Ralf Döblitz <doeblitz(a)doeblitz.net> wrote: > Willkommen in der Gateway-Hölle. Es gab schon gute Gründe, warum sich > damals einige Leute sehr deutlich gegen dieses Gateway ausgesprochen > haben. Sehr deutlich? Vielleicht im Usenet, aber in der Mailingliste wars immer "feine Sache, muss nur jemand mal einrichten". Und wie Ole sagte: also eigentlich ist das ja jetzt wohl kein so großes technisches Problem :) grüße, Marek

1 0

Re: [Python-de] Globaler "prefix" o.ae.
by Ole Streicher Sept. 13, 2011

Sept. 13, 2011

"Diez B. Roggisch" <deets(a)web.de> writes: > Python kann nicht mehr als das, was dir hier praesentiert wurde. Das > bescheidene "Design" des Original-Paketes es verhindert, die > eigentliche Ursache des Problems zu beseitigen. Und da du aussliesst > daran was aendern zu koennen, wirst du dich schon entscheiden muessen, > welchen Tod du stirbst.. Das wird mir auch langsam klar (obwohl ich immer noch die Hoffnung auf einen eigenen Loader/Finder habe...) Ich tendiere derzeit dazu, den Quelltext zu patchen. Gibt es Pythonpakete, die das erleichtern, ohne dass ich die verschiedenen Statements als regexp selber bauen muss? exec("from common.%s import %s" % (pkg, pkg)) wird man damit leider nicht fangen, aber glücklicherweise sind diese Statements dann doch abzählbar. Und da ließe sich sicher erreichen, dass diese Stellen Upstream durch entsprechende __import__()-Aufrufe ersetzt werden (die dann wieder durch einen Pythonparser gefunden werden). Viele Grüße Ole

2 1

Re: [Python-de] Globaler "prefix" o.ae.
by Ole Streicher Sept. 13, 2011

Sept. 13, 2011

"Diez B. Roggisch" <deets(a)web.de> writes: > Wichtig ist ja nur, dass die "boesen" Namen nicht mit anderen Paketen > kollidieren. Nur lässt sich dafür ganz einfach ein realistischer Usecase basteln: Wenn jemand die aktuelle Version des Pakets aus dem Upstream-CVS lädt, um sie mit der installierten Version zu vergleichen. ---------------8<------------------------------------------ from database import Database as DatabaseFromCVS from mypackage.database import Database as DatabaseFromStable stable_db = DatabaseFromStable() cvs_db = DatabaseFromCVS() ---------------8<------------------------------------------ Das wird ziemlich sicher einen wirren Mix von Versionen ergeben. Und es wird nicht zu vermitteln sein, warum das nicht funktioniert. Viele Grüße Ole

3 2

Re: [Python-de] Mailinglist-Gateway
by Ole Streicher Sept. 13, 2011

Sept. 13, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Am 13.09.2011 09:19, schrieb Ole Streicher: >> Ganz im Gegensatz zu den kulturellen: Diskussionskultur wurde ja schon >> angesprochen, aber es gibt in der Mail-Listen-Community auch die >> unangenehme Eigenschaft, Cc:s zu verschicken. Warum eigentlich? Wer >> auch immer in die ML postet, wird da auch direkt mitlesen. > > Auch das ist wohl primär ein technische Problem: Die Maisl über die ML kommen > mit folgenden Hadern: > > Newsgroups: de.comp.lang.python > To: python-de(a)python.org > From: Ole Streicher<ole-XXX> > Reply-To: Ole Streicher<ole-XXX>, > Die Deutsche Python Mailingliste<python-de(a)python.org> Aahh. Das liegt wohl daran, dass ich explizit ein Reply-To: gesetzt habe, welches sich vom From: unterscheidet. Und natürlich möchte ich gerne (falls es eine persönliche Antwort ist) über das Reply-To: kontaktiert werden, insofern ist das Erhalten dieses Headers durchaus sinnvoll. Eigentlich müsste die Liste eher ein List-Reply-To: Header basteln. Frage an die Gateway-Betreiber: wie habt Ihr Euch diesen Fall vorgestellt? Ole

1 0