[Python-de] Alptraum Unicode

[Stefan Schwarzer]

Hi Olaf,

On Sat, 2003-12-27 13:08:12 +0100, Olaf 'Ruebezahl' Radicke wrote:
> Am Samstag 27 Dezember 2003 02:56 schrieb Uwe Schmitt:
> > > die Codierung gerade eindeutig ist oder nicht. Das Leben mit Python
> > >
> > > > währe um einiges einfacher, wenn ein Unicode-String eine Klasse
> > > > (bzw. Typ) währe.
> >
> > aber unicode-strings sind doch ein typ/klasse in python...

dem stimme ich zu :)

> xml-string = ""
> #was habe ich jetzt UNICODE oder ASCII ?

>>> type('')
<type 'str'>
>>> type(u'')
<type 'unicode'>

> xml_string = socket_objekt.empfangen()
> #was habe ich jetzt UNICODE oder ASCII ?
> 
> sql_query = patser_objekt.run(xml_string)
> #was habe ich jetzt UNICODE oder ASCII ?
> 
> antwort = psql_objekt.query(sql_query)
> #was habe ich jetzt UNICODE oder ASCII ?
> 
> interaktions_string = Tkinter_gui_dialog.run(antwort)
> #was habe ich jetzt UNICODE oder ASCII ?

Das kommt auf die API der verwendeten Methoden an!

> Am Samstag 27 Dezember 2003 00:40 schrieb Stefan Schwarzer:
> > Sollte das blauäugig klingen, liegt es einfach daran, dass ich zu
> > wenig über dein Programm weiß. ;-) Nach deiner Beschreibung vermute
> > ich jedenfalls eher ein Design-Problem, und nicht so sehr, dass der
> > Umgang mit Unicode in Python notwendigerweise ekelhaft sein muss.
> 
> Volgende Funktion hat ein UNICODE-Fehler produzirt:
> 
> def _projekt_report(eltern_objekt, \
>                     project_title, \
>                     rekursiv, \
>                     mit_stammdaten_von, \
>                     epoch_begin, \
>                     epoch_end, \
>                     ausgabeformat):
> [ca. 150 Codezeilen gelöscht]

Deine Funktion tut m. E. viel zu viel:

- aufbauen von LaTeX-Code
- Datenbankzugriffe
- Zeichenkonvertierung
- diverse Fallunterscheidungen ("Fachlogik")

Ich glaube, unter diesen Bedingungen würde ich jede Menge Fehler
machen. Bei solchem Code verliert man den Überblick, und sogar Python
macht dann keinen Spaß mehr.

Vorschlag: Redesign.

Unter Vorbehalt (da ich deinen Code nicht gründlich gelesen habe),
schlage ich folgendes vor:

- Eine Klasse besorgt die Daten, die zur Fallunterscheidung und zum
  Aufbau der LaTeX-Datei notwendig sind. Alle zu lesenden
  Attribute/Methoden dieser Klasse geben Strings als Unicode-Objekte
  zurück.

- Eine andere Klasse kümmert sich um die Erzeugung von LaTeX-Dateien,
  alle Eingaben sind Unicode-Strings. Diese Klasse sollte nichts von
  deinem konkreten Problem wissen, also z. B. nur Methoden wie
  emph(unicode_object) oder begin_environment(unicode_object)
  enthalten. Möglicherweise kannst du so eine Klasse sogar aus einem
  anderen Projekt auftreiben und ggf. anpassen (falls deren Lizenz das
  zulässt).

- Schreibe deine Funktion unter Verwendung der beiden genannten
  Klassen. Diese Funktion enthält damit keine Datenbank-Zugriffe
  (nur indirekte, über die erste der beiden obigen Klasse) und
  schreibt auch keine LaTeX-Befehle in einer Datei. Darum kümmert sich
  wiederum die zweite der beiden oben genannten Klassen.

- Sollte es immer noch zu unübersichtlich sein, kannst du neue Klassen
  für Zeitarithmetik (gibt es schon massenhaft, z. B. das
  datetime-Modul in Python 2.3 oder mxDateTime) und/oder für Personen
  und/oder Checklisten einführen.

Die obige Aufzählung sehe ich nicht unbedingt als unumstößliche
Empfehlung, wie das Problem zu gliedern ist, sondern mehr als Anregung
für eigene Ideen. (Du kennst das Problem, das du lösen willst,
schließlich besser als ich.)

Wenn objektorientiertes Design neu für dich ist, schau dir mal diesen
URL an: http://c2.com/doc/oopsla89/paper.html . An deutschen Seiten
habe ich http://www.dfpug.de/konf/konf_1995/oop/SessionD-OOAD.htm und
http://www.google.de/search?q=cache:XelWpWFyahAJ:portal.dfpug.de/dFPUG/Dokumente/Konferenzen/VFP-Konferenz%25201998/D-CRC.doc+crc+card+object+-cyclic+-book&hl=de&lr=lang_de&ie=UTF-8
gefunden. Vielleicht gibt es auch hier etwas für dich:
http://directory.google.de/Top/World/Deutsch/Computer/Programmieren/Methoden/Objektorientiert/

Wichtig ist nicht nur, das Problem aufzuteilen, sondern auch, damit
aufzuhören. ;-) Du brauchst nur soweit aufzugliedern, dass du das
Problem lösen kannst, ohne allzuviele Abhängigkeiten gleichzeitig im
Kopf zu behalten. Falls auch andere Menschen den Code lesen und/oder
ändern müssen, musst du deren Kapazität, deinen Code zu überblicken,
berücksichtigen. Es kann also sein, dass du es noch einfacher machen
musst, als du es allein für dich brauchen würdest.

Viel Erfolg! :-)

Viele Grüße
 Stefan