Mailman 3 September 2011 - python-de

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

Sept. 12, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Am 11.09.2011 18:14, schrieb Ole Streicher: >> Hartmut Goebel<h.goebel(a)goebel-consult.de> writes: >>> Natürlich. Denn Du hast Module (oder Packages) "common" "databases", Es sind packages: Ein module ist (vereinfacht) eine Datei, während ein package eine Sammlung von modules ist. >>> etc. Aber es gibt keine Package "mypackage". Damit hast Du eine >>> Sammlung von Modulen, aber eben kein Package. Ein package ist aber genauso definiert: als eine Collection von Modulen. Dass das Design nicht perfekt ist, ist ja von mir unbestritten, aber es genügt den formalen Anforderungen an ein package. >> In dem Augenblick, in dem ich eine (auch leere) mypackage/__init__.py >> anlege, habe ich ein Package. > > Ja, aber common, database, etc. sind eben weiterhin einzelne Module (oder > Packages). Nur weil Du sie nach mypackage/ verschiebst, macht sie noch nicht > zu einem Teil von mypackage. Siehe Desgin-Fehler. > > Nur weil ich meinen VW in einer Mercedeswerkstatt reparieren lasse, ist es > noch immer kein Mercedes. ... womit mal wieder gezeigt ist, dass Autovergleiche meistens hinken: eine Handvoll pythonmodule in ein Verzeichnis gepackt und eine leere __init__.py angelegt macht daraus ein package, egal wie gut oder wie schlecht die Pakete auch sein mögen. >>> Jede "Lösung" (besser gesagt: Hack) wird Nebenwirkungen haben. >> Welche Hacks (bzw. Lösungen) gäbe es denn noch so und welche >> Nebenwirkungen wären zu erwarten? Vielleicht findet sich ja doch ein >> brauchbarer Kompromiss. > > Es läuft immer daraus hinaus, dass Du das Modul mypackages.common irgendwie > als common in den Namespace bekommen musst. Und damit kannst Du in diesem > Programm kein anderes Modul `common` mehr importieren. Solange man den namespace lokal halten kann (also nur innerhalb von common und database) wäre das ja kein Problem.

2 1

PyHosting sucht einen Admin
by Jens Diemer Sept. 12, 2011

Sept. 12, 2011

Das PyHosting-Projekt [1] sucht einen Linux-Administrator für den Shared-Hosting-Bereich. * Wer sind wir? * Wir sind eine GbR, die im Umlageverfahren einen gemeinsamen Dedicated Server (der bei Hetzner [2] steht) finanziert. Das Projekt existiert seit September 2006; wir sind derzeit 14 Gesellschafter. Jeder Gesellschafter hat ein Mitbestimmungsrecht. Kommuniziert wird meist über IRC, über eine geschlossene Mailingliste und ein MoinMoin Wiki. Der Server ist per Xen in mehrere Vserver-Instanzen aufgeteilt. Eine davon wird von z.Zt. 7 Leuten als Shared-Hosting-Service genutzt. * Wen suchen wir? * Wir suchen einen kompetenten Linux-Administrator, der Kenntnisse im Bereich Linux / unixoiden Systemen im Allgemeinen, der Virtualisierungsplattform Xen, Apache (oder auch anderen Webservern), MySQL und Mailservern besitzt. Deine Aufgaben sind Wartung und Sicherstellung eines einwandfreien Betriebs des existierenden Shared-Hosting-Vservers. Dazu gehört, das System sicher sowie up-to-date zu halten, die User bei Problemen (möglichst zeitnah) zu unterstützen und natürlich Freude bei der Arbeit. Wir bieten Dir die Möglichkeit, Deine Fähigkeiten im Realeinsatz unter Beweis zu stellen und Deine Erfahrung auszubauen. Du erhältst von uns natürlich die Möglichkeit, den Shared-Hosting-Server wie die anderen User zu nutzen; eine darüber hinaus gehende Vergütung können wir Dir nicht bieten. Interessenten werden gebeten, ihr Interesse via IRC (##pyhosting @ freenode) zu bekunden. Sofern Referenzen vorhanden sind, bitte angeben. [1] https://vserver.srv.alexanderweb.de/wiki/HostingProject/Features [2] http://www.hetzner.de/hosting/produkte_rootserver/eq4 -- Mfg. Jens Diemer ---- http://www.jensdiemer.de

1 0

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

Sept. 12, 2011

Frank Grellert <grellert(a)web.de> writes: > Wenn ich ein Package entwerfe, von dem ich vorher weiß, dass es sich > in unauflösbare Namenskonflikte mit bestehenden > Namensräumen begibt, muss ich einen anderen geeigneten Namensraum > suchen. Der "heilige Krieg", der hier ausgefochten wird, > ist kaum nachvollziehbar, vor allem wird immer unklarer, worauf Du > eigentlich hinauswillst. Im thread wurde Dir doch jetzt schon erklärt, > wie python packages Namensräume verwalten. [...] > Am 11. September 2011 19:46 schrieb Hartmut Goebel <h.goebel(a)goebel-consult.de>: >> Am 11.09.2011 18:14, schrieb Ole Streicher: TOFU ist nicht gerade geeignet, um herauszufinden, wem und worauf Du hier eigentlich antwortest. Falls Du Dich auf mich beziehst: Ich führe keinen heiligen Krieg, sondern ich habe ein konkretes Problem und suche dafür eine Lösung. Wie die Verwaltung der packagenamen normalerweise abläuft, ist mir auch klar; allerdings bietet Python eben die Möglichkeit, ziemlich tief einzugreifen -- ich nannte in einer anderen Mail schon die packages "imp", "importlib" und "pkgutil". Warum sollte sich mit denen nicht eine saubere Möglichkeit finden lassen, den lokalen Namespace zu verändern? Viele Grüße Ole

2 1

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

Sept. 11, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Natürlich. Denn Du hast Module (oder Packages) "common" "databases", > etc. Aber es gibt keine Package "mypackage". Damit hast Du eine > Sammlung von Modulen, aber eben kein Package. In dem Augenblick, in dem ich eine (auch leere) mypackage/__init__.py anlege, habe ich ein Package. >> exec("from common.%s import %s" % (cls, cls)) > Himmel hilf! (Aber auch das ließe sich mit einem sed-Befehl geheben) Klar. Es gibt aber auch exec("from %s.init.Setup import Setup" % target) und das ist deutlich schlimmer (aus dem Kontext ist immerhin zu erkennen, dass "target" etwas in der Region von "common" bzw. "database" ist). > Meine Anforderungen an Software-Qualität erfüllt das nicht. Und wenn > da schon solche offensichtlichen Klöpse drin sind, dann schlummern da > sicher noch ganz andere Bugs im Untergrund. Deine und meine Beurteilung der Softwarequalität ändert halt nur nichts am Problem. Wenn Bugs drin sind, werden die gemeldet und hoffentlich behoben. Dummerweise ist ein schlimmes Design eben kein Bug. > Jede "Lösung" (besser gesagt: Hack) wird Nebenwirkungen haben. Welche Hacks (bzw. Lösungen) gäbe es denn noch so und welche Nebenwirkungen wären zu erwarten? Vielleicht findet sich ja doch ein brauchbarer Kompromiss. Viele Grüße Ole

3 2

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

Sept. 11, 2011

Hartmut Goebel <h.goebel(a)goebel-consult.de> writes: > Jede "Lösung" (besser gesagt: Hack) wird Nebenwirkungen haben. Es gibt ja eine ganze Reihe von Python-packages, die sich um den Modulimport drehen; ein kompletter Abschnitt (30. in 2.7.2) beschäftigt sich damit: imp importlib imputil (deprecated) pkgutil ... Leider ist die Dokumentation in Bezug auf mein Problem da nicht so besonders erhellend. Hat da jemand Erfahrung mit? Viele Grüße Ole

1 0

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

Sept. 11, 2011

Stefan Schwarzer <sschwarzer(a)sschwarzer.net> writes: > Anscheinend ist die Software ja nicht dafür entworfen, als > Bibliothek von anderen verwendet zu werden. Doch :-) Wir sollen sie ja verwenden. Und sie ist durchaus universeller einsetzbar (innerhalb ihres Spezialgebietes). > Ich würde daher versuchen, dass Problem anders anzugehen: > Berichte dem Autor, auf welche Schwierigkeiten du gestoßen > bist, als du seine Software paketieren wolltest. Es ist nicht ein Autor, sondern ein Konsortium, welches die Software entwickelt. Mit den dazugehörigen schwerfälligen Entscheidungsprozessen sowie der Angst, irgendwas kaputtzumachen, wenn man grundlegende Änderungen vornimmt. Zumal wenn das Konsortium erstmal nicht direkt davon profitiert. Ansonsten: ja, klar wäre eine Lösung im Ausgangscode optimal. Nur gibt es dann eben das Kompatibilätsproblem zu den jetzigen Nutzern. (Das Paket ist in der Realität noch deutlich komplexer und enthält u.a. eine eigene Releaseverwaltung, die aber beim Debianpaket wegfallen wird). Viele Grüße Ole

2 2

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

Sept. 11, 2011

Hallo Diez, "Diez B. Roggisch" <deets(a)web.de> writes: > Ich habe das noch nie versucht, aber irgendwann mal mit jemandem darueber > diskutiert, ob es nicht moeglich waere, ein virtualenv mitzuinstallieren, um > darein dann Pakete installieren zu koennen, die im Konflikt mit im System > schon vorhandenen stehen. > > Das sollte eigentlich gehen. Unter /var/lib/<meinprogram>/ liegt dann ein > komplettes venv, mit deinen Quellen drin. Das /usr/bin/<meinprogram> bezieht > sich darauf, so dass beim Start der Pythonpath nur fuer deine Software > angepasst ist, und "import common" das richtige tut. Als Notfall-Lösung war das auch angedacht, zumal sie ja eigentlich ein eigenes Environment mitliefern (die daraus folgenden Probleme sind in Msg-Id: <ytz62l2hzir.fsf(a)news.ole.ath.cx> beschrieben). Nur ist das eben weit weg von Perfektion: wer was anderes machen will, z.B. ipython einsetzen, kann sich erstmal wieder durch die ganzen Feinheiten wühlen. Das möchte ich den Usern eigentlich nicht zumuten. Viele Grüße Ole

1 0

Python Memory Limits
by Thomas Lehmann Sept. 9, 2011

Sept. 9, 2011

Ich wüßte gerne inwieweit man die Grenzen in Python beeinflussen kann. Wenn ich bspw. eine Liste oder einen String erweitere wird irgendwann eine Exception geworfen. a) Wie kann ich die Limits abfragen b) Kann ich diese Grenzen beeinflussen (erhöhen)

6 7

"spezifischer" Pythonstart
by Ole Streicher Sept. 9, 2011

Sept. 9, 2011

Hallo Gruppe, ich muss mich gerade mit einem Programm herumschlagen, welches seinen eigenen Python-Interpreter mitbringt -- und zwar nur für den Zweck, sein eigenes Startup-Script "sitecustomize.py" zu erstellen. Die Datei sieht dann so aus: --------------------8<-------------------------------------------------- import sys if sys.executable.endswith('/grumlle): # Setup stuff for the "grumlle" program # ... del sys --------------------8<-------------------------------------------------- und es existiert ein Link /some/local/path/bin/grumlle -> python Das sieht für mich nicht so wahnsinnig elegant aus. Wie kann man das "transparent" (für den Nutzer) besser lösen? Bedingung ist, dass man (unter Linux resp. MacOSX) das Programm als "grumlle" aufruft und es das angegebene Setup durchführt. Eine Möglichkeit wäre ein Shellscript; allerdings habe ich keine Option gefunden, ein Startscript zu übergeben. Und eine Shell als Wrapper um einen Python-Start wäre auch nicht wirklich python-like. Gibt es nicht sowas wie --------------------8<-------------------------------------------------- #!/usr/bin/env python import grumlle.setup # executes the setup procedure del grumlle.setup do_everything_else() --------------------8<-------------------------------------------------- was man dann wie einen Python-Interpreter mit dem spezifischen Setup aufrufen kann? Viele Grüße Ole

1 0

Re: [Python-de] Datei löschen. Speicher wird nicht freigegeben
by Johannes Korn Sept. 7, 2011

Sept. 7, 2011

On 07.09.2011 12:20, Hartmut Goebel wrote:: > Am 07.09.2011 12:04, schrieb Johannes Korn: >> Ich habe zwei Methoden getestet, die Dateien zu löschen. > > M.E. ist das nicht die Stelle ist, an der das Problem liegt. > > Anscheinend hält der Prozess irgendwo noch Dateien offen. Kann es sein, > dass Du die temporären Dateien nicht schließt? Unter Unix hilft Dir > `lsof -p` die offenen Dateien zu finden. Ja, das war´s. Hatte versucht die Datei mit file.close zu schließen, statt mit file.close(). Merci!

3 2