Hallo zusammen,
ich möchte eine Liste von Strings an eine Funktion übergeben, die aber
ein File-Objekt erwartet. Gibt es eine Möglichkeit, die Liste
umzuwandeln? Bisher behelfe ich mir dadurch, dass ich die Liste in eine
temporäre Datei schreibe und daraus anschließend wieder lese. Das
scheint mir nicht sehr elegant.
Gruss,
Andreas
--
Andreas Grytz | http://www.linuxnewmedia.de
Stefan-George-Ring 24 | Tel: +49 (0) 89 993411-0
D-81929 München | Fax: +49 (0) 89 993411-99
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Hallo,
habe mir das Buch "blind" im Versandhandel bestellt. Besonders das
"Objektorientiert" im Titel klang vielversprechend.
Autor ist Michael Weigend. Von Ihm ist auch schon Python GE-PACKT aus dem
gleichen Verlag.
Aus Zeitgründn habe ich das Buch bisher nur angelesen und mal "querbeet"
durchgesehen. Die folgenden Aussagen bitte unter diesen Gesichtspunkt
betrachten.
Das Buch "Objektorientierte Programmierung mit Python" hat knapp 600
Seiten. Das Layout ist übersichtlich und klar, das Inhaltsverzeichnis
ausführlich. Der Index scheint mir etwas knapp zu sein.
Etwa die Hälfte des Buches ist eine Einführung in Python (es wird schon V
2.3 verwendet), wobei der Autor einen Schwerpunkt "auf die Erarbeitung von
Konzepten der Objektorientierung" gelegt haben will.
In der zweiten Hälfte wird relativ ausführlich Tkinter behandelt, außerdem
einige andere Themen, zB CGI-Programmierung, Internet, Datenbanken,
Threads, Fehlerbehandlung usw...
Außer den unvermeidlichen Listings enthält das Buch auch einige erklärende
Grafiken, einfache UML-Diagramme und einige EBNF-Grammatiken zur Syntax
von Python.
Der Autor pflegt einen sachlichen Still, die Beispiel, soweit ich sie mir
angesehen habe, wirken aber etwas "hölzern", so wie man sie aus manchen
Schulbüchern kennt. Jedes Kapitel hat am Schluß einen Aufgabenblock und
die Lösungen gibt es auch gleich dahinter.
Auf Grund des Titels hätte ich ein Buch erwartet, welches schon von
Python-Grundkentnissen beim Käufer ausgeht und nun die ganzen
Besonderheiten der "Objektorientierung" vertieft. Der Autor mag die
"Objektorientierung" mehr im Fokus haben, als das in anderen Büchern der
Fall ist, aber im Grunde scheint es mir im wesentlichen eine allgemeine
Einführung in Python (+ einiger Python-Libs wie zB Tkinter) zu sein.
Obwohl schon Pyton V2.3 verwendet wird, werden neue Python Funktionen -
wie zB Generatoren - nicht behandelt.
Zum Schluß noch eine merkwürdige Sache (die wohl kein Zufall sein kann!):
In allen Programmen werden keine Umlaute verwendet und es gibt auch keine
tieferen Informationen zum Thema Unicode (trotz eines eigenen Kapitels
über Zeichenketten)! Überall werden die Umlaute konsequent umschrieben
(ae, ue usw.). Beim Buch ist auch eine CD dabei, auf der alle
Beispielsourcen enthalten sind. Ich habe die durchsucht, keine Umlaute!
Warum das so ist, weiß ich nicht, aber gerade über Unicode hätte ich mir
ein ausführliches Kapitel gewünscht.
--
Mit freundlichen Grüßen
Klaus Meyer :-)
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Als sich Python "the agile programming language" nannte, habe ich das ja
erstmal ganz nett gefunden. Da flattert mit gestern in dem (an sich schon
ebenfalls komplett finsteren) Magazin "dotnetpro" eine Beilage für eine
Tagung (in München!) auf den Fisch äh Tisch:
http://www.oopconference.com
Und was findet man da? Zahnwurzelkräuselnden Buzzwortdreck der folgenden
Form:
"Evidence and Busines Case for Iterative or Agile Development"
"Agile best practices from everyday projects"
"Fit, Agil und Eclipse - Ein Erfolgsbericht"
"Agile Model Driven Development (AMDD)"
"Running Agile Software Development Projects with RUP"
"Principles and Practices of Agile Modeling (AM)"
"Agile und leichtgewichtige Vorgehensweise in der Entwicklung
sicherheitskritischer Anwendungen"
"Planning Agile Projects"
"Agiles Software-Engineering"
"Agile Database Techniques"
usw usf. Ist "Agil" das neue XML oder habe ich was verpasst?
(In dotnetpro war vor einiger Zeit eine Umfrage über Programmiersprachen.
Python hatte <1%. DUH: sie haben nur nach .NET Sprachen gefragt....)
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Hi,
nach einiger Zeit des Mitlesens heute auch mal mein erstes Statement.
> Was tun?
> Nicht in Euro-Komma-irgendwas rechnen sondern in Cent
> Komma Null. Bzw. bei der Tankstelle in 1/10 Cent und
> bei der Bank mit 1/100 oder 1/1000 Komma-Null rechnen
> und erst zum Schluss zurück rechnen. Aber so bald eine
> Kommerzahlen dabei ist, kann das Ergebnis abweichen.
Dieser Weg hat weiterhin seine Schwäche, denn er rundet nicht richtig und
verlagert die Problematik auch nur weiter nach hinten. Bei einer
entsprechenden Anzahl finanzieller Transaktionen kann dies dennoch
einträglich genug sein. Storries über die Ausnutzung dieses Problems gibt
es hinreichend. *g*
Die genaue Problematik hat Mike Cowlishaw, seines Zeichens IBM Fellow und
Entwickler von ReXX sehr schön unter
http://www2.hursley.ibm.com/decimal/decifaq.html
erläutert. Typischerweise nutzt man zur Lösung binär codierte
Dezimalzahlen, kurz BCD. Java unterstützt dies z.B. durch die Klasse
BigDecimal. Diese Konstrukte sind natürlich nicht so schnell wie Floating
Points via CPU, aber halt präzise.
Für Python gibt es, eine Google-Recherche sei Dank, auch eine Lösung unter
http://fixedpoint.sourceforge.net/
Diese Bibliothek ermöglicht Python eine präzise Festkomma-Arithmetik.
Allerdings habe ich sie selbst noch nicht auspobiert.
mue
--
**
** Frank Mueller / Oldenburg / Germany
**
** frank(a)mweb.de http://www.mweb.de
**
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Wieder mal die falsche Adresse...
-----Weitergeleitete Nachricht-----
From: Olaf 'Ruebezahl' Radicke <olaf_rad(a)gmx.de>
To: Axel Bringenberg <A.Bringenberg(a)srz-berlin.de>
Subject: Re: [Python-de] Wer nicht fragt, bleibt dumm
Date: 24 Nov 2003 23:05:03 +0100
Am Mon, 2003-11-24 um 18.29 schrieb Axel Bringenberg:
> Hat jemand ein Beispiel für mich, das bei 1.5.2 und älter "falsche"
> Ergebnisse liefert?
Nein, aber eine "Robinsoade":
Angenommen du schreibst ein Programm mit(bzw. für)
Geldbeträge. Wenn du dann riesige Summen mit Kommerzahlen
verrechnest und Python eifrig auf und ab rundet wird das
Ergebnis immer ungenauer ohne das du verstehst warum.
Denn kann es passieren das wenn du eine Durchschnittssumme
errechnest ein mal mit und ein mal ohne Zwischenschritte,
ein anderes Ergebnis herauskommt. Um so früher Python
auf und ab rundet um so ungenauer das Ergebnis.
Was tun?
Nicht in Euro-Komma-irgendwas rechnen sondern in Cent
Komma Null. Bzw. bei der Tankstelle in 1/10 Cent und
bei der Bank mit 1/100 oder 1/1000 Komma-Null rechnen
und erst zum Schluss zurück rechnen. Aber so bald eine
Kommerzahlen dabei ist, kann das Ergebnis abweichen.
MfG
Olaf
--
===================================================
"Meine Meinung steht fest. Bitte verwirren sie mich
nicht mit Tatsachen!"
Unbekannt.
===================================================
--
===================================================
"Meine Meinung steht fest. Bitte verwirren sie mich
nicht mit Tatsachen!"
Unbekannt.
===================================================
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Hallo Liste,
heute überraschte mich ein Kollege ;-) mit folgender Frage:
Wieso ist bei Python 1.5.2 ...
>>> 4.0 - 0.1
3.9
aber bei 2.1.3 und später ...
>>> 4.0 - 0.1
3.8999999999999999
Ich befürchte ja, dass diese Frage zu den FAQs gehört, habe aber trotz
intensivem Wühlen in Listen und Sites nichts wirklich erklärendes
gefunden - bin also für jeden Hinweis dankbar.
Gruß,
- bringi
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
-----Weitergeleitete Nachricht-----
From: Olaf 'Ruebezahl' Radicke <olaf_rad(a)gmx.de>
To: python-liste <python-de(a)python.net>
Subject: Re: "Typsicherheit" (war: Re: [Python-de] socket und umlaute)
Date: 23 Nov 2003 01:33:05 +0100
Am Sam, 2003-11-22 um 16.35 schrieb Stefan Schwarzer:
[..]
> Wenn du "langen verworrenen" Code hast, _schreit_ das nach
> Vereinfachung/Refaktorierung des Codes, unabhängig davon, ob die
> Verknüpfung eines Namens mit einem bestimmten Typ möglich ist oder
> nicht. :-) Letzteres flickt das eigentliche Problem nur sehr
> notdürftig.
OK. Um mal wieder vom "Allgemeinen" zum "Speziellen" zu kommen:
Ich habe eine Klasse "Config" die eine XML-Datei parst und die
Werte den anderen Klassen mit get-Methoden zur Verfügung stellt.
Jetzt habe ich ja meine Socket-Klasse und die braucht einen
Rechnernamen und ein Port. Der Rechnername ist ein str und
der Port ein unsigned int. Wo auf dem Weg von der XML-Datei
zur Socket-Instanz soll ich den str in ein int umwandeln, so
das später noch klar ist ab wo ich es mit was zu tun habe.
Wenn mir jetzt später ein fällt, ich will wissen ob eine
privilegierte Port-Nummer benutzt wird, muss ich den ganzen
Code durchgehen, wo immer der Wert mal durch gereicht wurde,
um sicher zu stellen, das diese Code auch das tut was ich
von ihm erwarte:
SUPERUSERPORTS = 1024
if conf.get_port_numder() <= SUPERUSERPORTS:
print "bist du wahnsinnig? Du benutzt Port:", conf.get_port_numder()
> Du kannst in Python nicht "aus einem int ein str" machen. Ein Objekt
> hat immer einen bestimmten Typ (außer vielleicht so pathologischen
> Fällen wie Zuweisungen an __class__ ;-) ). Meinst du eher "eine
> Funktion/Methode akzeptiert ein int und gibt ein str zurück"?
Ich will nicht ein und der selben Instanz mal dies, mal das
zuweisen dürfen und schon gar nicht Äpfel mit Birnen vergleichen.
Ich weiß das einige die Zeiger von C hassen, aber ich könnte mir
vorstellen, das man Objekte "TypenStatisch" macht und Zeiger
ein führt die auf alles zeigen dürfen nur nicht in's Nirvana.
So würde folgender Code immer noch gehen:
int_objekt = Klasse_1(int, 4)
str_objekt = Klasse_1(str, "4")
int_zeiger = Zeiger(int_objekt)
str_zeiger = Zeiger(str_objekt)
if int_zeiger == str_zeiger:
# geht
int_objekt == str_objekt
# lässt sich erst garnicht starten
int_objekt == int(str_objekt)
# Carsten ist auch noch ok.
Ganz neben bei kann dann auch wieder überladen werden.
Und ein
if long_double_oblekt_1 > long_duble_oblekt_2:
-Bedingung währe dann wahrscheinlich "teurer" als eine
if unsigned_int_oblekt_1 > unsigned_int_oblekt_2:
-Bedingung.
> Wenn ja,
> musst du die Schnittstellen deiner Module/Klassen/Methoden/Funktionen
> so entwerfen, dass sie nicht nur irgendwie dein Problem lösen, sondern
> auch intuitiv - d. h. ohne genaue Kenntnis der inneren Implementierung
> - benutzbar sind.
Vielleicht könnte man auch einfach ein Interpreter-Schalter
"-Typ_Pedantc"
machen, der darauf hinweist, wenn man einem Objekt unterschiedlich
verwendet.
> > Für C und C++ sind meine Projekte zu klein (auch personell)
> > als das der Aufwand noch in Relation zum Nutzen stände.
>
> C oder C++ zu verwenden hat m. E. nichts mit der Größe des Projekts zu
> tun, sondern mit der Art des Projekts. Ich kann mir gut vorstellen,
> dass auch für viele "große" Projekte Python weitaus besser als C/C++
> geeignet ist/wäre.
Ich werde in meinem Code XML in LaTeX parsen. Das ging
in C++ rasant schnell. Ich werde sehen was Python dabei
für eine Figur macht. Was Größe angeht, hat Zope und Mailman
usw. gezeigt was geht.
MfG
Olaf
--
===================================================
"Meine Meinung steht fest. Bitte verwirren sie mich
nicht mit Tatsachen!"
Unbekannt.
===================================================
--
===================================================
"Meine Meinung steht fest. Bitte verwirren sie mich
nicht mit Tatsachen!"
Unbekannt.
===================================================
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Hallo Olaf,
On Sat, 2003-11-22 13:50:32 +0100, Olaf 'Ruebezahl' Radicke wrote:
> Alles schön und gut. Eine so hohe Abstraktion mag seine
> Vorteile haben. Aber es währe noch schöner wenn ich
> die *Möglichkeit* hätte, Typen so zu deklarieren das
> ich z.B. nicht mehr einfach eine Variable mal als str mal
> int benutzen kann. Weil wenn ich ein ziemlich langen
> verworrenen Code habe, wie soll ich da raus finden,
> ob ich jetzt ein int oder ein str vor mir hab? Selbst
> wenn ich im Code nach einer Zuweisung suche kann ich
> Pech haben und in irgend einer unterfunktion wird da
> stillschweigend aus ein int ein str gemacht. Eh ich
> den Fehler gefunden habe, können Tage vergehen.
Wenn du "langen verworrenen" Code hast, _schreit_ das nach
Vereinfachung/Refaktorierung des Codes, unabhängig davon, ob die
Verknüpfung eines Namens mit einem bestimmten Typ möglich ist oder
nicht. :-) Letzteres flickt das eigentliche Problem nur sehr
notdürftig.
Du kannst in Python nicht "aus einem int ein str" machen. Ein Objekt
hat immer einen bestimmten Typ (außer vielleicht so pathologischen
Fällen wie Zuweisungen an __class__ ;-) ). Meinst du eher "eine
Funktion/Methode akzeptiert ein int und gibt ein str zurück"? Wenn ja,
musst du die Schnittstellen deiner Module/Klassen/Methoden/Funktionen
so entwerfen, dass sie nicht nur irgendwie dein Problem lösen, sondern
auch intuitiv - d. h. ohne genaue Kenntnis der inneren Implementierung
- benutzbar sind. Vielleicht habe ich dich bzw. dein Problem auch
nicht richtig verstanden und bin auf dem falschen Dampfer. :-)
> Ich könnte mir eine Klasse bzw. Typ "StaticTyp" Vorstellen:
>
> int_vier = StaticTyp(int, "4")
> str_vier = StaticTyp(str, "4")
>
> try:
> if int_vier == str_vier:
> print "kein Fehler"
> except StaticTypError, par:
> print "So ja nicht: ", par
Du könntest diese Klasse StaticTyp, soweit ich sehe, in Python
schreiben. Das wäre allerdings nur begrenzt wirksam, da viele von
Python's eingebauten oder in Modulen vorliegenden Hilfsmitteln nach
wie vor gewöhnliche "ints" und "strs" zurückgeben würden.
Nichtsdestotrotz bin ich ziemlich sicher, dass dein Problem anders
gelöst werden kann - und sollte - als mit statischer Typbindung.
> PS:
> Was meine Programmiererfahrung betrifft. In den letzten
> ca. 2 Jahren habe ich mich mit C, C++ und Perl beschäftigt.
> Perl war meine erste Sprache, die ich aber sehr schnell
> verwarf, weil sich Python wesentlich leichter debuggen lässt.
Das ging mir auch so und war der Grund für die Abkehr von Perl:
Manchmal ging die Zeit, die ich beim vermeintlichen "Einfach-so-
hinschreiben-können" gespart hatte, wieder für die Fehlersuche drauf.
Meine Fehler in Python-Code (zumindest die, die ich finde ;-) ) sind
dagegen eher trivial und schnell zu beheben, oder selten.
> Für C und C++ sind meine Projekte zu klein (auch personell)
> als das der Aufwand noch in Relation zum Nutzen stände.
C oder C++ zu verwenden hat m. E. nichts mit der Größe des Projekts zu
tun, sondern mit der Art des Projekts. Ich kann mir gut vorstellen,
dass auch für viele "große" Projekte Python weitaus besser als C/C++
geeignet ist/wäre.
Viele Grüße
Stefan
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Hallo zusammen,
ich entwickel gerade ein s.g. Debug-Tool für Zope mit einer GUI
geschrieben in wxPython. Dieses soll die Abarbeitung der Request und
Response Vorgänge dementsprechend abbilden. Das tool wird per Schleife
den Medusa-Server "belauschen" und ein List-object regelmässig updaten.
Nun zu meinem Problem: Wie nutze ich eine Schleife unter wxPython, ohne
das die GUI hängt(z.B. mit einer while, größeren for-Schleife).
im Prinzip müsste es etwas sein wie: schaue alle n Sekunden nach und
dann tu etwas?!
Danke und Gruß
Axel
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de
Am Fre, 2003-11-21 um 21.53 schrieb gerhard quell:
> Hallo Ruebezahl,
>
> Du mußt auch bei PostgreSQL Deinen Zeichensatz einstellen:
>
> z.B. aus PyPgSQL:
> self.dbcrs.execute("SET DATESTYLE TO German")
> und zusätzlich auf der Datenbank Latin-1 einstellen
> z.B.: createdb -E latin-1 -e testdb2
>
> Ohne Einstellung benutzt Du 7 Bit Ascii
Ich glaube das reicht mir. Bis auf das Euro-Zeichen
ist da alles drinnen was ich brauche.
Olaf
--
===================================================
"Meine Meinung steht fest. Bitte verwirren sie mich
nicht mit Tatsachen!"
Unbekannt.
===================================================
_______________________________________________
Python-de maillist - Python-de(a)python.net
http://python.net/mailman/listinfo/python-de