Hallo,
als neuling will ich mein Programm für mehrere Sprachen auslegen, die passenden Routinen habe ich schon geschrieben (gettext).
Wo ich mir aber noch ziemlich unsicher bin ist die Art der umsetzung, sprich soll ich die gettext routinen gleich am Anfang des Programms ausführen
oder lieber alles in eine Funktion packen und dann in der Hauptschleife initialisieren, das hat aber wie ich finde einen Nachteil da meine Funktionen so nicht
mit übersetzt werden.
Wie ist die Empfehlung?
MfG Friedduck
Internationalisierung
-
BlackJack
@friedduck: Ich verstehe die Frage irgendwie nicht. Das `gettext`-System muss initialisiert werden bevor das erste mal eine Übersetzung gemacht wird. Also ziemlich am Anfang des Programmablaufs. Das ist doch irgendwie offensichtlich.
Hi,
es kann ja sein das die Frage sinnfrei ist, aber da ich noch recht neu in der Python Welt bin wollte ich halt wissen wie man es "pythonischer" macht.
Was gemeint ist:
1. Beispiel:
import bla
gettext code
weitere Funktionen
hauptschleife
2. Beispiel
import bla
def translate():
weitere Funktionen
hauptschleife
translate()
Ich hoffe ich habe es jetzt etwas verständlicher ausgedrückt.
Aber ich denke mal du hast recht, es macht viel mehr Sinn gettext gleich als erstes, nach dem Imports zu initialisieren.
es kann ja sein das die Frage sinnfrei ist, aber da ich noch recht neu in der Python Welt bin wollte ich halt wissen wie man es "pythonischer" macht.
Was gemeint ist:
1. Beispiel:
import bla
gettext code
weitere Funktionen
hauptschleife
2. Beispiel
import bla
def translate():
weitere Funktionen
hauptschleife
translate()
Ich hoffe ich habe es jetzt etwas verständlicher ausgedrückt.
Aber ich denke mal du hast recht, es macht viel mehr Sinn gettext gleich als erstes, nach dem Imports zu initialisieren.
-
BlackJack
@friedduck: Ich würde weder 1. noch 2. machen sondern als erstes im regulären Programmablauf initialisieren. Also am Anfang der Hauptfunktion. Wenn man das auf Modulebene nach den Importen macht, dann kann man das Modul nicht ohne Seiteneffekt importieren. Und 2. macht keinen Sinn, denn *nach* der Hauptschleife ist das Programm ja bereits ohne Übersetzung gelaufen.
Hi, das war gestern wohl zu spät.
Nach der heutigen Lektüre des Threads, sehe ich das wir aneinander vorbeigeredet haben und das der 2te Beispiel
etwas irretierend ist. Der richtige weg scheint zu sein:
Oder?
Nach der heutigen Lektüre des Threads, sehe ich das wir aneinander vorbeigeredet haben und das der 2te Beispiel
etwas irretierend ist. Der richtige weg scheint zu sein:
Code: Alles auswählen
import gettext
def starttranslation():
weitere module
if __name__ == '__main__':
starttranslation()
weiterer Programmablauf
Dies ist IMHO keine Frage, wie man es möglichst pythonisch angeht, sondern einfach eine Sache der guten Programmstruktur...
Und ja, wenn deine Initialisierungen über die Möglichkeiten von gettext.install hinausgehen, dann kannst du das durchaus eine eigene Funktion auslagern:
Und ja, wenn deine Initialisierungen über die Möglichkeiten von gettext.install hinausgehen, dann kannst du das durchaus eine eigene Funktion auslagern:
Code: Alles auswählen
def main():
_init_gettext()
# restlicher Programmcode
if __name__ == '__main__':
main()Das meinte ich mit "pythonisch"... Mir fehlt halt noch das Gefühl für die richtige strukturierung des Codes.snafu hat geschrieben:Dies ist IMHO keine Frage, wie man es möglichst pythonisch angeht, sondern einfach eine Sache der guten Programmstruktur...
Vielen Dank an euch beide, meine Frage wurde mehr als ausreichend beantwortet.
-
BlackJack
@friedduck: Falls in Deinem letzten Beispiel das „weitere Module” hinter dem ``def starttranslation():`` andeuten sollte, dass nach der Funktionsdefinition weitere ``import``-Anweisungen folgen, dann würde ich sagen das ist unkonventionell. Üblicherweise kommen erst die Importe und dann erst Definitionen im Modul selbst. Es bringt ja auch überhaupt keinen Vorteil oder generell irgend einen wahrnehmbaren Effekt wenn man das ``def`` vor weitere Importe zieht. Einzige Ausnahme: man hat zirkuläre Importe, die das verwenden wollen. *Dann* hat man aber ganz andere Probleme. 
Nein, das ist nicht so. Vll. wäre die Bezeichnung "Funktionen" passender gewesen. Aber heissen die Funktionen in Python nicht auch Module?BlackJack hat geschrieben:@friedduck: Falls in Deinem letzten Beispiel das „weitere Module” hinter dem ``def starttranslation():`` andeuten sollte, dass nach der Funktionsdefinition weitere ``import``-Anweisungen folgen, dann würde ich sagen das ist unkonventionell.
Die Aufteilung bei Python ist ja:
importbereich
funktionsbereich (modulbereich?)
hauptprogrammcode
Oder bin ich hier wieder auf dem Holzweg?
Sorry, wenn wir hier die Grundlagen durchkauen müssen...
-
BlackJack
@friedduck: Ein Modul ist üblicherweise der Code, der aus einer Quelltextdatei erstellt wird und damit bei der Ausführung definiert welche Namen in dem Modul existieren. Oder anders ausgedrückt welche Attribute auf dem Modul-Objekt existieren. Funktionen sind keine Module.
Die drei Bereiche, die Du aufzählst, sind alle Bestandteil von einem Modul und zumindest technisch sind die nicht vorgeschrieben. Man kann die ja mischen, also auch Code auf Modulebene vor die Importe schreiben, der weder ``import`` noch Definition von Funktionen (oder Klassen) ist. Die Trennung in diese drei Bereiche sind „nur” eine Konvention, damit man als Leser/Programmierer eine Struktur hat in der man sich leichert zurecht finden kann. Damit man im Quelltext des Moduls nicht verstreute ``import``-Anweisungen oder Codeschnippsel suchen muss um zu verstehen was dort vor sich geht.
Die drei Bereiche, die Du aufzählst, sind alle Bestandteil von einem Modul und zumindest technisch sind die nicht vorgeschrieben. Man kann die ja mischen, also auch Code auf Modulebene vor die Importe schreiben, der weder ``import`` noch Definition von Funktionen (oder Klassen) ist. Die Trennung in diese drei Bereiche sind „nur” eine Konvention, damit man als Leser/Programmierer eine Struktur hat in der man sich leichert zurecht finden kann. Damit man im Quelltext des Moduls nicht verstreute ``import``-Anweisungen oder Codeschnippsel suchen muss um zu verstehen was dort vor sich geht.
ok, danke für die Erklärung. Jetzt verstehe ich einiges mehr.
Je tiefer ich Python einsteige, desto mehr mag ich die Sprache.
Was ich aber nicht verstehe, ist warum Python so ein Underdog unter den Sprachen ist (ist halt meine Persönliche einschätzung, kann sein dass ich mich irre), wo doch wirklich alles vorhanden
ist um richtig schöne Anwendungen zu entwickeln und die Syntax ist doch wirklich nicht zu schwer...
Die Portierbarkeit ist ja auch nicht von schlechten Eltern, ich hab z.B Python auf meiner Fritzbox laufen mit Bottle, als
ersatz für den schweren Apache, ich finds einfach nur geil.
Je tiefer ich Python einsteige, desto mehr mag ich die Sprache.
Was ich aber nicht verstehe, ist warum Python so ein Underdog unter den Sprachen ist (ist halt meine Persönliche einschätzung, kann sein dass ich mich irre), wo doch wirklich alles vorhanden
ist um richtig schöne Anwendungen zu entwickeln und die Syntax ist doch wirklich nicht zu schwer...
Die Portierbarkeit ist ja auch nicht von schlechten Eltern, ich hab z.B Python auf meiner Fritzbox laufen mit Bottle, als
ersatz für den schweren Apache, ich finds einfach nur geil.
-
BlackJack
@friedduck: Wie kommt die Einschätzung „Underdog” denn zustande? Unter den dynamisch typisierten Programmiersprachen ist es eine feste Grösse. Wenn man davon ausgeht, dass ein guter Programmierer mindestens eine allgemeine, dynamisch typisierte Programmiersprache in seinem „Werkzeugkasten” haben sollte, um Aufgaben erledigen zu können, für die statisch typisierte Sprachen üblicherweise zu unhandlich sind, hat man bei den verbreiteten Sprachen die Wahl zwischen Perl, Python, und Ruby. Mittlerweile vielleicht auch noch JavaScript via NodeJS. Die dürften auch alle auf Geräten von der Leistungsstärke (oder -schwäche ) von einem Router benutzbar sein.
) von einem Router benutzbar sein.@BlackJack: Wie genau meine Einschätzung zustande kommt, kann ich auch nicht plausibel erklären.
Naja wenn man sich so umschaut z.B bei der Webentwicklung ist PHP und Ruby sehr verbreitet,
fast jedes CMS oder die Colaborative Software ist in PHP geschrieben. Von Python hört man eher nichts.
Auch das Hosting ist mehr auf PHP zugeschnitten, ich denke mal Provider die Python hosten, kann man
an einer Hand abzählen.
Verstehst du wie ich das meine?
Aber naja, bevor wir hier einen Flamewar lostreten...
Meine Fragen sind ja beantwortet und das zählt. Danke!
Naja wenn man sich so umschaut z.B bei der Webentwicklung ist PHP und Ruby sehr verbreitet,
fast jedes CMS oder die Colaborative Software ist in PHP geschrieben. Von Python hört man eher nichts.
Auch das Hosting ist mehr auf PHP zugeschnitten, ich denke mal Provider die Python hosten, kann man
an einer Hand abzählen.
Verstehst du wie ich das meine?
Aber naja, bevor wir hier einen Flamewar lostreten...
Meine Fragen sind ja beantwortet und das zählt. Danke!
-
BlackJack
@friedduck: PHP ist halt bei jedem Billighoster vorhanden. Das hat zum Teil historische Gründe, und zum Teil wollen die Hoster keine „richtigen” Webanwendungen haben, mit Laufzeiten die den Anfrage/Antwort-Zyklus den man beim PHP-Laufzeitmodell hat, überschreiten. Genau das machen aber so ziemlich alle anderen Rahmenwerke für Webanwendungen in anderen Programmiersprachen. Da gibt es in der Regel einen Webanwendungsserver der die Anwendung ausführt und ständig läuft. Wenn man so etwas möchte muss man sich einen Hoster suchen, der das anbietet, oder selber hosten. Und sich in der Regel auch entsprechend bezahlen lässt.
Mit dieser „PHP ist überall”-Sicht müsste man aber auch ASP.NET (C# & Co.) und J2EE (Java & Co.) die Verbreitung bei der Webentwicklung absprechen. Was wohl nicht der Realität entspräche.
Für Python in der Webentwicklung gibt es durchaus grosse Beispiele. Google Dienste (Google App Engine, Youtube, …), Disqus, Dropbox, um mal ein Paar zu nennen. Dann die beiden grossen Rahmenwerke Zope/Plone und Django mit denen auch ein paar Entwickler ihre Brötchen verdienen in dem sie Webanwenungen für Kunden schreiben.
Mit dieser „PHP ist überall”-Sicht müsste man aber auch ASP.NET (C# & Co.) und J2EE (Java & Co.) die Verbreitung bei der Webentwicklung absprechen. Was wohl nicht der Realität entspräche.
Für Python in der Webentwicklung gibt es durchaus grosse Beispiele. Google Dienste (Google App Engine, Youtube, …), Disqus, Dropbox, um mal ein Paar zu nennen. Dann die beiden grossen Rahmenwerke Zope/Plone und Django mit denen auch ein paar Entwickler ihre Brötchen verdienen in dem sie Webanwenungen für Kunden schreiben.
Das wusste ich nicht und es freut mich umso mehr, ich für meinen Teil bin von Python überzeugt und will ein paar Projekte damit umsetzen.BlackJack hat geschrieben: Für Python in der Webentwicklung gibt es durchaus grosse Beispiele. Google Dienste (Google App Engine, Youtube, …), Disqus, Dropbox, um mal ein Paar zu nennen. Dann die beiden grossen Rahmenwerke Zope/Plone und Django mit denen auch ein paar Entwickler ihre Brötchen verdienen in dem sie Webanwenungen für Kunden schreiben.
Python wird jetzt quasi mein "daily driver"
Gott, ich seh grade dass wir 2 Seiten vollgelabbert haben
