Re: AW: [Python-de] Re: Alptraum Unicode
...So, eine nacht später und etwas abgeregt... 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...
xml-string = "" #was habe ich jetzt UNICODE oder ASCII ? 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 ? 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): latex_code = "" latex_code += "\\section{Projektziel}\n" if project_title != "Dachprojekt": latex_code += "Das Projekt ist abgeleitet von dem Projekt \\glqq " test_str = "" latex_code += test_str.encode("Latin-1") eltern_projekt = db_querys.get_parent_from(eltern_objekt, project_title) latex_code += _sonderzeichen_behandlung(eltern_projekt) projekt_id = db_querys.get_id_from_project(eltern_objekt, project_title) latex_code += " \\grqq{} (Projekt-ID: " + str(projekt_id) + ") \n \\\\ \n \\\\" latex_code += "Das Projektziel war wie folgt formuliert: " projekt_ziel = db_querys.get_project_conception(eltern_objekt, project_title) latex_code += _sonderzeichen_behandlung(projekt_ziel) latex_code += " \n" #return latex_code dagesdatum = unix_time.Unix_Time() # die Tagesdoku dict_list = db_querys.get_docu_epoch(eltern_objekt, project_title, epoch_begin, epoch_end) if len(dict_list) > 0: latex_code += "\\section{Tagesdokumentation}\n" for dic_tages_doku in dict_list: latex_code += "\n \\subsubsection{" dagesdatum.set_sekunden(dic_tages_doku['datum']) latex_code += dagesdatum.get_nice_string() latex_code += "geschrieben von " mittarbeiter_id = dic_tages_doku['mittarbeiter_id'] log_name = db_querys.get_logname(eltern_objekt, mittarbeiter_id) log_name = _sonderzeichen_behandlung(log_name) real_name = db_querys.get_realname(eltern_objekt, mittarbeiter_id) real_name = _sonderzeichen_behandlung(real_name) latex_code += real_name + "(" + log_name + ")}\n" latex_code += _sonderzeichen_behandlung(dic_tages_doku['tages_doku']) # ToDo's dict_list = db_querys.get_todo_epoch(eltern_objekt, project_title, epoch_begin, epoch_end) if len(dict_list) > 0: latex_code += "\\section{Erledigte Aufgaben}\n" for dic_todo_doku in dict_list: latex_code += "\n\\subsubsection{" dagesdatum.set_sekunden(dic_todo_doku['datum']) latex_code += dagesdatum.get_nice_string() latex_code += "erledigt von " mittarbeiter_id = dic_todo_doku['mittarbeiter_id'] log_name = db_querys.get_logname(eltern_objekt, mittarbeiter_id) log_name = _sonderzeichen_behandlung(log_name) real_name = db_querys.get_realname(eltern_objekt, mittarbeiter_id) real_name = _sonderzeichen_behandlung(real_name) latex_code += real_name + "(" + log_name + ")} \n" latex_code += "\emph{ Zusammenfassung: }" latex_code += _sonderzeichen_behandlung(dic_todo_doku['zusammenfassung']) + " \\\\ \n" latex_code += unicode("\emph{ Erg�zung: }","latin-1") #^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # Hopla! wieso muste ich hier expliziet "unicode" ? latex_code += _sonderzeichen_behandlung(dic_todo_doku['beschreibung']) # Checklisten all_name_of_checkpoint = db_querys.get_checklist_from(eltern_objekt, project_title) if len(all_name_of_checkpoint) > 0: # gibt es berhaubt eine Checkliste latex_code += "\\section{Checkliste(n)}\n" for checkpoint in all_name_of_checkpoint: latex_code += "\\subsection{ \glqq " + checkpoint + "\grqq{} }\n" latex_code += "\\begin{center} \n" latex_code += "\\begin{longtable}{|l|l|l|}" latex_code += "\\hline \n" latex_code += "Datum & Zeitdifferenz & Login-Name" latex_code += "\\\\ \\hline \\hline \n" dict_list = db_querys.get_checkpoint_epoch(eltern_objekt, project_title, checkpoint, epoch_begin, epoch_end) if len(dict_list) > 0: # wurden Eintragungen gemacht zu dem Checkpoint letztes_datum = unix_time.Unix_Time() for dic_check_doku in dict_list: mitarbeiter_id = dic_check_doku['mittarbeiter_id'] logname = db_querys.get_logname(eltern_objekt, mitarbeiter_id) logname = _sonderzeichen_behandlung(logname) datum = unix_time.Unix_Time() datum.set_sekunden(dic_check_doku['datum']) diff_time = unix_time.Unix_Time() diff_time.set_sekunden(0) if letztes_datum.get_sekunden_int() != 0: # ist das nicht der erste eintrag # rechne differenz aus diff_sek = datum.get_sekunden_int() - letztes_datum.get_sekunden_int() diff_time.set_sekunden(datum.get_sekunden_int() - letztes_datum.get_sekunden_int()) latex_code += datum.get_nice_string() + " & " latex_code += diff_time.get_tag_s_m_str() + " & " latex_code += logname latex_code += "\\\\ \\hline \n" letztes_datum.set_sekunden(datum.get_sekunden_int()) latex_code += "\\end{longtable} \n" latex_code += "\\end{center} \n" # Abschlussbericht projekt_status = db_querys.get_project_status(eltern_objekt, project_title) if projekt_status == "p": # ist das Projekt abgeschlossen... latex_code += "\\section{Abschlussbericht}\n" dict_list += db_querys.get_abschlussbericht(eltern_objekt, project_title) if len(dict_list) > 0: # wurden Eintragungen gemacht zu dem Checkpoint for abschluss_dict in dict_list: latex_code += "\\emph{Geschrien von" mitarbeiter_id = abschluss_dict['mittarbeiter_id'] logname = db_querys.get_logname(eltern_objekt, mittarbeiter_id) logname = _sonderzeichen_behandlung(logname) real_name = db_querys.get_realname(eltern_objekt, mittarbeiter_id) real_name = _sonderzeichen_behandlung(real_name) latex_code += real_name + " (" + logname + ") am " datum = unix_time.Unix_Time() datum.set_sekunden(abschluss_dict['datum']) latex_code += datum.get_nice_string() + "} \\\\ \n" latex_code += _sonderzeichen_behandlung(abschluss_dict['bericht']) return latex_code.encode("Latin-1") #^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # und hier muste ich wieder "encode" mit das Risulat eindeutig # für den entfänger ist. ######################################################## #################### der Empfänger: ###################### def get_report( eltern_objekt, \ project_title, \ rekursiv, \ mit_stammdaten_von, \ epoch_begin, \ epoch_end, \ ausgabeformat): conf = eltern_objekt.get_conf() report_begin = unix_time.Unix_Time() report_begin.set_sekunden(epoch_begin) report_ende = unix_time.Unix_Time() report_ende.set_sekunden(epoch_end) if _ist_zugriff_von_ip_erlaubt(eltern_objekt) == 0: return "<error>keine ausreichende Ber�htigung!</error>" # Vorspann latex_code = "% Diese datei wurde automatisch von GNUSWork generiert \n\n" latex_code = "\\documentclass[10pt,a4paper]{article}\n" latex_code += "\\usepackage[latin1]{inputenc}\n" latex_code += "\\usepackage{german}\n" latex_code += "\\usepackage{pslatex}\n" latex_code += "\\usepackage{rotating}\n" latex_code += "\\usepackage{longtable}\n" latex_code += "\\usepackage[T1]{fontenc}\n\n" latex_code += "\\usepackage{booktabs}\n" latex_code += "\\usepackage{pst-all}\n" latex_code += "\\usepackage{multido}\n" latex_code += "\\setlength{\\parindent}{0pt}\n" latex_code += "\\begin{document}\n" # Kopf latex_code += "\\title{\\textbf{" latex_code += _sonderzeichen_behandlung(project_title) latex_code += "} \\\\ \n \\normalsize (Report beginnt: " latex_code += report_begin.get_nice_string() latex_code += " Report ende: " + report_ende.get_nice_string() latex_code += " ) }\n" latex_code += "\\author{" einrichtungsadresse = db_querys.get_headproject_addess(eltern_objekt) latex_code += _sonderzeichen_behandlung(einrichtungsadresse) latex_code += "}\n" latex_code += "\\maketitle\n" latex_code += "\\tableofcontents\n" latex_code += "\\newpage\n" # Haubtteil # stammdaten if mit_stammdaten_von != "": latex_code += "\\section{Stammdaten}\n" latex_code += "\\begin{longtable}{p{8cm} }\n" tab_list = db_querys.get_reiter_from_stammdaten(eltern_objekt, mit_stammdaten_von) for tab in tab_list: reiter = _sonderzeichen_behandlung(tab) data = db_querys.get_daten_from_stammdaten(eltern_objekt, mit_stammdaten_von, tab) blatt = _sonderzeichen_behandlung(data) latex_code += "\\toprule \n" latex_code += "\\specialrule{1pt}{1pt}{1pt} \n" latex_code += "\\textbf{ " latex_code += reiter + " }" latex_code += "\\\\ \\midrule \n" latex_code += blatt + " \\\\ \n " print"#################### reiter/blatt: ",reiter,"/",blatt latex_code += "\\end{longtable} \n" print"erstelle Haubtprojekt " if rekursiv == 1: latex_code += "\n \\part{Haubtprojekt: " + project_title + "} \n" latex_code += _projekt_report( eltern_objekt, \ project_title, \ rekursiv, \ mit_stammdaten_von, \ epoch_begin, \ epoch_end, \ ausgabeformat) # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # Wieso zur Höle ist "latex_code" an dieser stell kein UNICODE?! _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Olaf 'Ruebezahl' Radicke schrieb:
...So, eine nacht später und etwas abgeregt...
Zweifellos ist es schwierig externe Programme einzubinden. Du kennst "Die Feuerzangenbowle" ? <Slangmode ein>"... Was is a Dampfmaschin ..." Wenn man nicht weiß wie es geht, oder gehen könnte, kann man immer noch den alten Entdeckergeist einschalten, und wie oben schon angedeutet in den schwarzen Kasten etwas reintun und sehen was unten rauskommt. Wenn Du das getan hast, kannst Du Dein Programm entsprechend abändern. Wie Stefan schon angedeutet hat, ist es eine Frage des Designs, lieber mal 2 Stunden intensiv vor Verwirklichung grübeln und dann programmieren. Späteres Flicken ist ziemlich schwierig, habe ich selber gerade erlebt. PS. Ist Dein Code Open Source? Wenn ja: "Kauf Dich ein Duden, mich hat's auch gehelft." Sorry, mußte sein. Gruß Mike _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Am Samstag 27 Dezember 2003 16:34 schrieb Mike Abel:
Olaf 'Ruebezahl' Radicke schrieb: [...] Wie Stefan schon angedeutet hat, ist es eine Frage des Designs, lieber mal 2 Stunden intensiv vor Verwirklichung grübeln und dann programmieren. Späteres Flicken ist ziemlich schwierig, habe ich selber gerade erlebt.
...mal 2 Stunden... **KREISCH**! Ich arbeite seid Ende April'03 an dem Projekt! Ich habe kein zwei Stunden über über meine GUI nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine XML-API nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meinen LaTeX -F**K nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine DB nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine Klassen nach gedacht sondern Tage... Man! Dein Beitrag hat mir echt geholfen. An der Stelle ein herzliches Danke an Stefan. Der Code-Teil ist einer der wenigen Teile, die ich aus der Vorleuferversion "FreePriority" (in C++ geschrieben) übernommen habe. Die hässlichsten Stellen hast du noch nicht mal gesehen, aber deine Anregungen werde ich so oder so ähnlich umsetzen.
PS. Ist Dein Code Open Source? Wenn ja: "Kauf Dich ein Duden, mich hat's auch gehelft."
Ja, das ist ja das tolle an Open-Source! Die Fehler die dir gefallen, kannst du alle übernehmen und in dein eigenen Code einbauen. Allerdings musst du deine Fehler dann auch allen frei zur Verfügung stellen. Aber du willst alle Fehler für dich alleine haben - nicht war? Aber z.Z. bin ich noch der einzigste Fehler-Entwickler im Team und habe das alleinige geistige Eigentum. Wenn du mir fiel Geld bietest, mach ich es wie Trolltech. Ich gebe dann eine Lizenz-Version raus, bei der du an niemanden sagen musst, wo du deine Fehler her hast. Ach ja, und den Spruch kennst du ja auch: "Ein geklauten Gaul, schaut man nicht in's Maul". MfG Olaf _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Olaf, ich habe mal mit 4 Leuten an einem kommerziellen Projekt 2 Jahre gearbeitet und dann meinem Kunden gesagt, daß Projekt müsse gestoppt werden (break) um zu redesignen :-). Der hätte mich fast erschlagen und einen Herzinfakt bekommen (wahrscheinlich in der Reihenfolge). Nur wir haben uns 2 Wochen zusammengesetzt, die Systemanalyse noch mal gemacht und dann das ganze Teil neu designed. Nach weiteren 4 Wochen war das Programm neu programmiert und läuft seit dem produktiv. Damals gab es aber noch nicht so schöne Bücher wie von Martin Fowler - Refactoring! Also, erzähl nichts, Du hast noch nicht mal ein Mannjahr investiert und bist jetzt gerade so weit, wieder von vorn anzufangen :-). Oder anders ausgedrückt, nimm einmal an, Dein ganzer bisher geschriebene Quellcode ist futsch - was machst Du dann?? Gruß Gerhard ------------- Olaf 'Ruebezahl' Radicke wrote:
...mal 2 Stunden... **KREISCH**! Ich arbeite seid Ende April'03 an dem Projekt! Ich habe kein zwei Stunden über über meine GUI nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine XML-API nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meinen LaTeX -F**K nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine DB nach gedacht sondern Tage; Ich habe kein zwei Stunden über über meine Klassen nach gedacht sondern Tage...
Man! Dein Beitrag hat mir echt geholfen.
-- ------------------------------------------------------ skequell ------ Gerhard Quell Software & Knowledge Engineering Schützenweg 3 eMail: gquell@skequell.de Fon: 0731-26400651 89275 Elchingen web : http://www.skequell.de Fax: 0731-26400652 ---Aus Sicherheitsgründen: bitte keine Word-, Excel-Dateianhänge ----- _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
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(u'')
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... 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 _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Olaf 'Ruebezahl' Radicke wrote:
xml-string = "" #was habe ich jetzt UNICODE oder ASCII ?
Weder noch: xml-string ist vom
xml_string = socket_objekt.empfangen() #was habe ich jetzt UNICODE oder ASCII ?
Byte-String.
sql_query = patser_objekt.run(xml_string) #was habe ich jetzt UNICODE oder ASCII ?
Hängt von patser_objekt ab. Wenn Du nicht sicher bist und es nicht dokumentiert ist, solltest Du assert isinstance(sql_query, unicode) schreiben.
antwort = psql_objekt.query(sql_query) #was habe ich jetzt UNICODE oder ASCII ?
Genauso.
interaktions_string = Tkinter_gui_dialog.run(antwort) #was habe ich jetzt UNICODE oder ASCII ?
Wenn die Zeichen ausschliesslich ASCII sind, hast Du einen Byte-String, ansonsten einen Unicode-String. Wenn Du immer einen Unicode-String haben willst, solltest Du interaktions_string = unicode(interaktions_string) schreiben.
latex_code += test_str.encode("Latin-1")
Hier eine fragliche Design-Entscheidung: latex_code soll offenbar Latin-1 kodiert sein. Wenn man den String inkrementell aufbaut, muss man dann sicherstellen, dass jeder Teil auch Latin-1 ist. Alternativ kannst Du latex_code als Unicode-String aufbauen, und die Sonderzeichenbehandlung ganz am Ende durchführen. Für das inkrementelle Aufbauen empfehle ich, nicht += zu verwenden, sondern eine Liste. Du kannst am Ende überprüfen, ob alle Elemente der Liste wirklich Byte-Strings sind, bevor Du sie verkettest (per "".join(liste))
dagesdatum.set_sekunden(dic_tages_doku['datum']) latex_code += dagesdatum.get_nice_string()
Potentiell ein Unicode-String. Da Du die Absicht hast, dass latex_code ein byte_string wird, solltest Du sicherstellen, dass es auch einer ist: dagesdatum = dagesdatum.get_nice_string() assert isinstance(dagesdatum, str) latex_code += dagesdatum
latex_code += unicode("\emph{ Erg�änzung: }","latin-1") #^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # Hopla! wieso muste ich hier expliziet "unicode" ?
Das muss Dich stutzig machen. Ein String, den Du addiert hast, ist offenbar ein Unicode-String. Du solltest herausfinden, welcher das ist, und ihn dann in Latin-1 konvertieren.
latex_code += _sonderzeichen_behandlung(dic_todo_doku['beschreibung'])
Und hier kracht's dann. Soweit ich verstanden habe, gibt _sonderzeichen_behandlung einen Byte-String zurück, während latex_code inzwischen ein Unicode-String ist. Damit wird das system default encoding verwendet, um das Ergebnis von _sonderzeichen_behandlung in Unicode zu konvertieren. Falls Du das system default encoding nicht geändert hast (was Du *nie* tun solltest), gibt diese Operation einen UnicodeError, sowie die Beschreibung wirklich Sonderzeichen enthält.
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # Wieso zur Höle ist "latex_code" an dieser stell kein UNICODE?!
Da habe ich was nicht verstanden: latex_code sollte doch ein Byte-String sein, kein Unicode-String???? Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
O.K. mir ist in den letzten Mails doch einiges etwas klarer geworden. Ich glaube es jetzt begriffen zu haben. MfG Olaf _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
aber unicode-strings sind doch ein typ/klasse in python...
xml-string = "" #was habe ich jetzt UNICODE oder ASCII ?
klassischer string....
xml_string = socket_objekt.empfangen() #was habe ich jetzt UNICODE oder ASCII ?
klassischer string....
sql_query = patser_objekt.run(xml_string) #was habe ich jetzt UNICODE oder ASCII ?
print type(sql_query) oder dbapi2 nachlesen
antwort = psql_objekt.query(sql_query) #was habe ich jetzt UNICODE oder ASCII ?
dito
interaktions_string = Tkinter_gui_dialog.run(antwort) #was habe ich jetzt UNICODE oder ASCII ?
klassischer string (imho)... ansonsten: print wie oben... gruss, uwe _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
Hi, ich lass den geposteten Spaghetti-Code mal weg, ist für eine Liste/Newsgroup/... eh viel zu lange... Ich würde Olaf nebenbei mal eine Template-engine empfehlen, z.b. emPy... Es macht doch keinen Sinn wenn 90% des Codes nur fallbasiert Texte zusammenklebt... Gruß, Uwe _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
[Uwe Schmitt Sun, Dec 28, 2003 at 12:47:47PM +0100]
Hi,
ich lass den geposteten Spaghetti-Code mal weg, ist für eine Liste/Newsgroup/... eh viel zu lange...
Hmmm, ich finde, es gibt keinen guten Grund, solche abfaelligen Bemerkungen ("Spagetti Code") zu schreiben, selbst wenn der gepostete Code lang ist. Probleme mit Unicode sind ziemlich typisch und ich glaube, fast jeder hat da eine Konfusionsphase durchlebt. Natuerlich koenntest Du, Olaf, auch darauf verzichten, alles was schief laueft, auf die Sprache zu schieben :-) Wie auch immer, ich habe im uebrigen Martin's Postings und Ratschlaege bzgl. Unicode in der Vergangenheit sehr genau gelesen und seitdem keine Unicode-Probleme mehr in meinen Applikationen (Danke, uebrigens!). Und wie auch Stefan schon sagte, man sollte sich fuer eigene APIs sehr genau ueberlegen, ob etwas unicode oder bytestrings produziert. Als Faustregel sehe ich: intern *immer* unicode objekte verwenden und bei Interaktionen mit fremden Subsystemen (xml-parser, latex-output etc.) die Encodings ermitteln/produzieren, aber intern weiterhin alles in unicode halten. Beispiele: - wenn ich eine Hilfsfunktion habe, die eine Konfig-Datei einliest, dann erwarte ich von vorneherin *nur* unicode zeichenketten, so dass ich nicht ueberall im Programm wissen muss, welches encoding ein Bytestring denn nun gerade haben koennte. - Wenn ich eine Webpage generiere, dann habe ich das "<html>..." zeug komplett als unicode objekt und erst ganz zum Schluss wird ein bytestring mit einem encoding draus (das auch im html-header spezifiziert sein muss). Ich glaube, vieles waere einfacher, wenn man die automatische Konvertierung (Coercion) von Bytestrings nach unicode-zeichenketten wenigstens zu debug-zwecken komplett unterbinden koennte. Der automatische Versuch, bei einer 'bytestring + unicodestring' Operation den bytestring als US-ASCII kodiert zu betrachten und implizit in ein Unicode-Objekt zu wandeln, ist vielleicht "convenient" (insbesondere fuer US-spezifische Applikationen :-) aber fuehrt eben manchmal zu schwer debugbaren Problemen. gruss und viel erfolg bei der Bewaeltigung von Unicode :-) holger _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
holger krekel wrote:
Ich glaube, vieles waere einfacher, wenn man die automatische Konvertierung (Coercion) von Bytestrings nach unicode-zeichenketten wenigstens zu debug-zwecken komplett unterbinden koennte.
Kann man: In site.py ändere man in if 0: # Enable to switch off string to Unicode coercion and implicit # Unicode to string conversion. encoding = "undefined" die 0 in ein True (besser: in sitecustomize.py schreibe man sys.setdefaultencoding("undefined")). Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
[Martin v. Loewis Sun, Dec 28, 2003 at 01:19:32PM +0100]
holger krekel wrote:
Ich glaube, vieles waere einfacher, wenn man die automatische Konvertierung (Coercion) von Bytestrings nach unicode-zeichenketten wenigstens zu debug-zwecken komplett unterbinden koennte.
Kann man: In site.py ändere man in
if 0: # Enable to switch off string to Unicode coercion and implicit # Unicode to string conversion. encoding = "undefined"
die 0 in ein True (besser: in sitecustomize.py schreibe man sys.setdefaultencoding("undefined")).
Und teilst du die Auffassung, dass das eine gute Methode waere, um unicode-bugs zu beheben? gruss, holger _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
holger krekel wrote:
Und teilst du die Auffassung, dass das eine gute Methode waere, um unicode-bugs zu beheben?
Ich hab's noch nie probiert. Vermutlich stellt man fest, dass man an vielen Stellen im Quelltext ein u" vor die Strings schreiben muss. Wenn man das akzeptieren kann, führt es sicher zu stabilerem Code. Ciao, Martin _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
[Uwe Schmitt Sun, Dec 28, 2003 at 12:47:47PM +0100]
Hi,
ich lass den geposteten Spaghetti-Code mal weg, ist für eine Liste/Newsgroup/... eh viel zu lange...
Hmmm, ich finde, es gibt keinen guten Grund, solche abfaelligen Bemerkungen ("Spagetti Code") zu schreiben, selbst wenn der gepostete Code lang ist.
War eigentlich nicht wertend gemeint,...
Als Faustregel sehe ich:
intern *immer* unicode objekte verwenden und bei Interaktionen mit fremden Subsystemen (xml-parser, latex-output etc.) die Encodings ermitteln/produzieren, aber intern weiterhin alles in unicode halten.
Genau diese Vorgehensweise führt zu einer großen Wiederverwendbarkeit und Orthogonalität der einzelnen Komponenten.
Ich glaube, vieles waere einfacher, wenn man die automatische Konvertierung (Coercion) von Bytestrings nach unicode-zeichenketten wenigstens zu debug-zwecken komplett unterbinden koennte. Der automatische Versuch, bei einer 'bytestring + unicodestring' Operation den bytestring als US-ASCII kodiert zu betrachten und implizit in ein Unicode-Objekt zu wandeln, ist vielleicht "convenient" (insbesondere fuer US-spezifische Applikationen :-) aber fuehrt eben manchmal zu schwer debugbaren Problemen.
Ich benutze daher "%s%s" % (str1, str2) bzw. u"%s%s" % (str1, str2) statt str1+str2. Gibt mehr Fehlermeldungen aus, und man sieht dem Code auch an, was am Ende rauskommt.. Gruß, Uwe _______________________________________________ Python-de maillist - Python-de@python.net http://python.net/mailman/listinfo/python-de
participants (7)
-
gerhard quell -
holger krekel -
Martin v. Loewis -
Mike Abel -
Olaf 'Ruebezahl' Radicke -
Stefan Schwarzer -
Uwe Schmitt