[Fwd: Re: "Typsicherheit" (war: Re: [Python-de] socket und umlaute)]

Olaf 'Ruebezahl' Radicke olaf_rad at gmx.de
Son Nov 23 09:08:12 CET 2003


-----Weitergeleitete Nachricht-----

From: Olaf 'Ruebezahl' Radicke <olaf_rad at gmx.de>
To: python-liste <python-de at 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.
===================================================