Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #4961 > unrolled thread

[Python-de] Source code generation is a stupid idea

Back to article view | Back to de.comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [Python-de] Source code generation is a stupid idea Thomas Güttler <guettliml@thomas-guettler.de> - 2017-10-13 11:50 +0200
    Re: [Python-de] Source code generation is a stupid idea "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2017-10-13 14:26 +0200
    Re: [Python-de] Source code generation is a stupid idea Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-16 05:30 +0200
      Re: [Python-de] Source code generation is a stupid idea Achim Domma <domma@procoders.net> - 2017-10-16 11:05 +0200
      [Python-de] Bitte widersprechen Thomas Güttler <guettliml@thomas-guettler.de> - 2017-10-16 16:35 +0200
      Re: [Python-de] Bitte widersprechen Achim Domma <domma@procoders.net> - 2017-10-17 01:23 +0200
        Re: [Python-de] Bitte widersprechen Thomas Güttler <guettliml@thomas-guettler.de> - 2017-10-17 09:42 +0200
        Re: [Python-de] Bitte widersprechen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-17 19:45 +0200
        Re: [Python-de] Bitte widersprechen "Schmitt  Uwe (ID SIS)" <uwe.schmitt@id.ethz.ch> - 2017-10-17 18:31 +0000

#4961 — [Python-de] Source code generation is a stupid idea

Hallo,

danke für das Feedback!

ich habe den Abschnitt "Source code generation is a stupid idea" überarbeitet:

   https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea

Ist es nun besser?

Gruß,
  Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [next] | [standalone]

#4964

On 2017-10-13 09:50, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
> danke für das Feedback!
>
> ich habe den Abschnitt "Source code generation is a stupid idea" überarbeitet:
>
>    https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea
>
> Ist es nun besser?

Nicht wirklich. Im ersten Absatz schreibst Du im Wesentlichen "Compiler
sind eine blöde Idee". Ein Programm das ein File in einer Sprache
hernimmt und daraus ein eines in einer anderen Sprache erzeugt, ist ein
Compiler. Ein Programm, das das Input-File direkt verarbeitet, ist ein
Interpreter.

Diese Aussage halte ich für unsinnig. Compiler sind nicht nur keine
blöde Idee, sondern ziemlich notwendig. Generell übersetzen Compiler von
einer "höheren" in eine "niedrigere" Sprache. Die "höhere" Sprache hat
für den Programmierer den Vorteil, dass sie ihm Arbeit erspart, die
"niedrigere" hat den Vorteil, dass bereits ein Interpreter (oder
Compiler) dafür existiert.

Richtig ist, dass das, was der Compiler ausspuckt, nicht "Source Code"
ist. Auch dann nicht, wenn es Code in einer Sprache ist, die (auch) zum
Schreiben von Source Code verwendet wird, wie C, JavaScript, Python oder
Assembler. Der Source Code ist der Input des Compilers, also das was Du
als "DATA" bezeichnest.

Deine Exception 1 halte ich auch für unsinnig: Warum soll man aus einer
Syntax-Beschreibung nicht gleich einen kompletten Parser erzeugen, wenn
es möglich ist? (Und ja, auch in diesem Fall ist der Output kein
Source-Code. Der Source-Code ist die Syntax-Beschreibung.)

Schließlich der Fall, den Du überhaupt nicht erwähnst (es sei denn, Du
meinst das mit Exception 1), obwohl er der einzige ist, in dem
tatsächlich Source-Code generiert wird, in dem Sinne, dass er vom
Benutzer editiert werden soll: Das Generieren von *unvollständigem* Code
aus einer abstrakteren Beschreibung, wie z.B. einer IDL (wie von Dir
erwähnt) oder UML oder ähnlichem. Das halte ich tatsächlich für eine
blöde Idee. Denn wenn sich der Input ändert (und das wird vorkommen),
dann wird ein echtes Source-File überschrieben und man muss im
günstigsten Fall die eigenen Änderungen wieder reinmergen, im
ungünstigsten neu schreiben.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#4968

Am 13.10.2017 um 11:50 schrieb Thomas Güttler:

> ich habe den Abschnitt "Source code generation is a stupid idea" 
> überarbeitet:

> https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea 
Wenn Du
http://www.99-bottles-of-beer.net/language-common-lisp-114.html
automatisch nach Python konvertieren würdest,
könntest Du das Programm anschießend vielleicht
auch verstehen.

Hermann
    der der vermutet, wenn regexpr nach Python code
    (und nach Modifikation zurück) konvertiert würde,
    er derartige Ausdrücke besser debuggen könnte

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#4969

On Monday, 16 October, 2017 05:30 AM, Hermann Riemann wrote:
> Am 13.10.2017 um 11:50 schrieb Thomas Güttler:
> 
>> ich habe den Abschnitt "Source code generation is a stupid idea"
>> überarbeitet:
> 
>> https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea
> 
> Wenn Du
> http://www.99-bottles-of-beer.net/language-common-lisp-114.html
> automatisch nach Python konvertieren würdest,
> könntest Du das Programm anschießend vielleicht
> auch verstehen.

Ich habe den Abschnitt über Code Generation gelesen, den Rest des
Dokuments überflogen und würde in mehr Punkten widersprechen als
zustimmen. Bezogen auf Code Generation finde ich obigen Verweis auf Lisp
sehr schön, weil dadurch folgende Behauptung widerlegt wird:

"Don't confuse data and code. Imagine you have a source code generator
which takes DATA as input and creates SOURCE as output."

Ausführbarer Code besteht einfach nur aus Daten. Es ist quasi Teil der
Idee von Lisp, daß ein Programm "nur" eine Liste von Anweisungen ist.
Ergo gibt's die Unterscheidung zwischen Code und Daten in der Form nicht
wirklich. Wo man nun die Grenze zwischen "(ausführbarem) Code" und
"Sourcecode" zieht, ist 'ne andere Diskussion, was aber nichts an meiner
Meinung ändert:

Mit Code Generation kann man sich spektakulär selbst ins Knie schießen.
Man sollte wissen was man tut. Dadurch wird das Werkzeug als solches
nicht schlechter. Würde ich in einem Umfeld programmieren wollen, in dem
man mich aller gefährlichen Optionen (und damit Möglichkeiten) beraubt,
würde ich Java programmieren. ;-)

Grüße,
Achim

[toc] | [prev] | [next] | [standalone]

#4971 — [Python-de] Bitte widersprechen

Am 16.10.2017 um 11:05 schrieb Achim Domma:
> On Monday, 16 October, 2017 05:30 AM, Hermann Riemann wrote:
>> Am 13.10.2017 um 11:50 schrieb Thomas Güttler:
>>
>>> ich habe den Abschnitt "Source code generation is a stupid idea"
>>> überarbeitet:
>>
>>> https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea
>>
>> Wenn Du
>> http://www.99-bottles-of-beer.net/language-common-lisp-114.html
>> automatisch nach Python konvertieren würdest,
>> könntest Du das Programm anschießend vielleicht
>> auch verstehen.
> 
> Ich habe den Abschnitt über Code Generation gelesen, den Rest des
> Dokuments überflogen und würde in mehr Punkten widersprechen als
> zustimmen. 

Dann tu es bitte. Bitte widerspreche zu konkreten Punkten mit klaren Argumenten.
Das würde mich freuen.


> Bezogen auf Code Generation finde ich obigen Verweis auf Lisp
> sehr schön, weil dadurch folgende Behauptung widerlegt wird:
> 
> "Don't confuse data and code. Imagine you have a source code generator
> which takes DATA as input and creates SOURCE as output."
> 
> Ausführbarer Code besteht einfach nur aus Daten.

Ich habe mit Lisp gearbeitet und bin sehr froh, dass nicht mehr zu tun.
Ich habe relationale Datenbanken erst nicht leiden können. Jetzt
sehe ich selten einen Grund wo anders Daten zu speichern.

SQL ist super langweilig aber auch super schnell und mächtig.
Ich nutze nur PostgreSQL zu anderen DBs kann ich nicht viel sagen.


> Es ist quasi Teil der
> Idee von Lisp, daß ein Programm "nur" eine Liste von Anweisungen ist.
> Ergo gibt's die Unterscheidung zwischen Code und Daten in der Form nicht
> wirklich. Wo man nun die Grenze zwischen "(ausführbarem) Code" und
> "Sourcecode" zieht, ist 'ne andere Diskussion, was aber nichts an meiner
> Meinung ändert:
> 
> Mit Code Generation kann man sich spektakulär selbst ins Knie schießen.

Dann sind wir ja einer Meinung


> Man sollte wissen was man tut. Dadurch wird das Werkzeug als solches
> nicht schlechter. Würde ich in einem Umfeld programmieren wollen, in dem
> man mich aller gefährlichen Optionen (und damit Möglichkeiten) beraubt,
> würde ich Java programmieren. ;-)

Gruß,
   Thomas

-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#4978 — Re: [Python-de] Bitte widersprechen

On Monday, 16 October, 2017 04:35 PM, Thomas Güttler wrote:
> Dann tu es bitte. Bitte widerspreche zu konkreten Punkten mit klaren
> Argumenten.
> Das würde mich freuen.

Ich tendiere bei sowas etwas ruppig rüber zu kommen und über's Ziel
hinaus zu schießen. Da ich aber gerade im Süden bei immer noch 25+ Grad
auf einem Balkon sitze, versuche ich's mal! ;-)

Du schreibst oben zwar, daß es sich nur um deine Ansichten und nicht um
die einzige Wahrheit handelt, die Ausführungen unten sind aber genau so
geschrieben, als wären sie absolut. Für weniger erfahrene Entwickler
oder Anfänger (dein Zielpublikum) ist es absolut unmöglich zu erkennen,
was deine persönliche Perferenzen sind und für welche Aussagen du gute
Gründe hast. Selbst wenn du gute Gründe hast, sind diese evtl. nur in
"deiner Welt" valide oder eben auf deinem aktuellen "Skilllevel". Es ist
natürlich legitim, diesen Stand zu dokumentieren. Meiner Ansicht und
Erfahrung nach, richtest du damit aber mehr Schaden als Nutzen an, wenn
du den Kontext und Hintergrund nicht explizit machst.

Jetzt aber ganz konkret:

- 10-Finger-Tippen: Sollte man in meinen Augen können, aber ist es
wirklich so wichtig? Wieviel Zeit verbringst du mit Schreiben von Code
und wieviel mit Lesen?

- SQL ist kein bißchen langweilig. Wie kommst du darauf? In "meiner
Welt" würde ich NIEMALS einem Tool eine Datenmigration überlassen. Dafür
sind die Datenmengen viel zu groß. Und ganz sicher würde ich nicht
Django verwenden. Wenn überhaupt ein ORM, dann SqlAlchemy. Das heißt
nicht, daß deine Aussage falsch ist. Mir fehlt nur - wie oben
beschrieben - der Kontext. Deine Aussage paßt auf ein SEHR
eingeschränkten Bereich von Problemen. Selbiges gilt für NoSQL: Ich bin
da auch kein großer Fan davon und froh, daß "meine" Sachen noch mit
Postgersql lösbar sind. Aber es gibt nunmal Probleme, für die wirst du
Cassandra brauchen.

- Conditional data structures: Das Argument zählt nur für SEHR einfache
GUI Anwendungen. Da ist dein "empty"-Place eine einfache Lösung. In den
meisten Fällen wirst du für "empty" trotzdem Spezialbehandlungen haben
und dann eine "magic number" in der Gegend rum reichen müssen. Für mich
hat Displaylogik nichts in den Daten zu suchen. Wenn's den Platz nicht
gibt, gehört für mich da ein NULL hin. Damit umzugehen ist Aufgabe der GUI.

- Nullable boolean columns: No way! Mag sein, daß das wieder für
einfache GUIs paßt, aber in "meiner Welt" hat in der Datenbank zu
stehen, was die Daten ausdrücken wollen. Dazu muß der Entwickler
natürlich wissen, was NULL ist und wie man damit umgeht.

- Avoid nullable character columns: In "meiner Welt" auch indiskutabel.
Wie oben: Wenn dein Ansatz für dich paßt, ist das ok. Aber die Aussage
gilt in der Form nicht allgemein. Für mich macht es oft einen großen
Unterschied, ob der String explizit da, aber leer ist, oder ob er gar
nicht gefüllt ist/war.

- Beim CRD Absatz verstehe ich nicht wirklich, was du sagen willst.

- Avoid Threads and Async: Was machst du denn auf Multicore-Maschinen?
Sagen wir 64 Cores? Ja, du kannst mehrere Prozesse starten, was das
Debugging nicht gerade leichter macht. Je nach Szenario verbrennst du
dann jede Menge Rechenzeit mit der Interprozesskommunikation. Und im
Fall von extremem IO kommt nichts an die Performance mit async in Kombi
mit mehreren Prozessen. Und in anderen Fällen sind Threads die
einfachste und effizienteste Lösung auf solchen Maschinen. Du hattest ja
oben KISS erwähnt. Um dem zu folgen zu können, sollte man alle Optionen
kennen und können.

- Source code generation is a stupid idea: Hast du da schon was geändert
oder hatte ich vorher oberflächlich gelesen? Mir scheint der Absatz
jetzt mehr auf "SOURCE code" zu fokussieren, womit ich besser leben
kann. Der Punkt ist ein großes Thema, dem deine Ausführungen nicht
gerecht werden. Ich halte es heute für eine schlechte Idee, mit
Texttemplates o.ä. Source Code zu erzeugen und diesen dann zu
compilieren oder auszuführen. Daneben gibt es aber 1001 andere Optionen,
die die Schwachpunkte dieses Ansatzes nicht haben. Im übirgen bin ich
mir recht sicher, daß TypeScript nicht textbasiert in Javascript
übersetzt wird. Ohne es geprüft zu haben, würde ich Wetten annehmen, daß
TypeScript in eine Art AST übersetzt und dieser dann als JavaScript
serialisiert wird.

- Regex: Ähnlich wie oben bei SQL: "Know your tools" und den Kontext.
Ja, es ist Bullshit, mit Regex JSON & Co parsen zu wollen. Das ist aber
kein Regex-Problem sondern ein Userproblem. Ein Entwickler, der seine
Hausaufgaben gemacht hat, weiß, daß man z.B. HTML eigentlich nicht
wirklich mit Regex parsen kann. Aber wenn du z.B. in einem Freitext nach
"auschließlich Zahlen in Klammern" suchst, sind Regex nicht zu
übertreffen. Ja, ist nicht der Usecase, den du beschrieben hast. Meiner
aber schon.

- Keep custom IDE configuration small: Also doch vi benutzen? ;-)

- Passing around methods ...: Ich mag Python u.a. weil ich mehrere
Paradigmen zur Hand habe. Und stellst du gerade den Sinn von
funktionaler Programmierung in Frage?

- "git rebase" vs "git merge": Das Ergebnis ist nicht nur Sourcecode.
Das Ergebnis ist auch die History, die ich mir anschauen kann. Je nach
Projekt und Anforderungen macht merge vs rebase einen riesen Unterschied.

- This is untestable code: Ich habe noch niemanden gesehen, der diese
Argumentation mit ausreichend großen und komplexen Datenmengen aufrecht
erhalten kann. ;-)

- Learn one programming language, not ten: Du kennst "Pragmatic
Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das
würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur
in diesen Strukturen denken und hat in der Regel Scheuklappen an.
Javaentwickler können oft z.B. nur OO denken.

Soweit erstmal. Nur nochmal zur Sicherheit: Ich behaupte nicht, daß
deine Aussage grundsetzlich falsch wären. Aber sie sind auch nicht so
allgemeingültig, wie sie formuliert sind. Und das ist für dein
Zielpublikum irreführend.

Grüße,
Achim

[toc] | [prev] | [next] | [standalone]

#4980 — Re: [Python-de] Bitte widersprechen

Am 17.10.2017 um 01:48 schrieb Stefan Ram:
> Achim Domma <domma@procoders.net> writes:
>> - Learn one programming language, not ten: Du kennst "Pragmatic
>> Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das
>> würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur
>> in diesen Strukturen denken und hat in der Regel Scheuklappen an.
>> Javaentwickler können oft z.B. nur OO denken.
> 
>    Ich würde auf dem Gebiet der Anzahl der zu erlernenden
>    Programmiersprachen anderen Menschen keine Regeln vorgeben
>    wollen, aber für mich selber würde ich es bevorzugen, mich
>    auf eine oder auf ganz wenige Sprachen konzentrieren zu können.
>    (Aus praktischen Gründen muß ich derzeit mehr
>    Programmiersprachen [zumindest deren Grundlagen]
>    erlernen als mir eigentlich lieb ist.)

Na super. Dann sind wir doch genau einer Meinung.

Bitte die Überschrift nicht aus den Augen verlieren: Das sind meine persönlichen
Guidelines für mich. Ich mache sie nur öffentlich verfügbar.
Insbesondere darum, damit man mich kritisieren kann. Ich versuche dann
aus der Kritik Verbesserungsvorschläge abzuleiten. Klappt nicht immer, aber oft.

Gruß,
  Thomas



-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#4988 — Re: [Python-de] Bitte widersprechen

Am 17.10.2017 um 01:48 schrieb Stefan Ram:
> Achim Domma <domma@procoders.net> writes:

>> - Learn one programming language, not ten: Du kennst "Pragmatic
>> Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen.

Nach welcher Auswahl?
http://www.99-bottles-of-beer.net/abc.html

>> Wer nur eine oder zwei Sprachen kann, kann nur
>> in diesen Strukturen denken

Ein echter Programmierer
https://www.bernd-leitenberger.de/echte-programmierer.shtml
programmiert in jeder Sprache FORTRAN

>> und hat in der Regel Scheuklappen an.
>> Javaentwickler können oft z.B. nur OO denken.

Anfangs waren Klassen für mich auch nur schlechter Ersatz
für Strukturen, und sind es teilweise auch noch.

So verwende ich für Python Projekte
class GLobal:
und irgendwo g=Global() ..
in denen ich alle globale Daten unterbringe,
so das ich sie überall mit g.irgendwas ansprechen kann.
( das habe ich in C auch so gemacht, nur mit struct statt class)

>    Ich würde auf dem Gebiet der Anzahl der zu erlernenden
>    Programmiersprachen anderen Menschen keine Regeln vorgeben
>    wollen,

Die Anzahl halte ich nicht für so wichtig wie die Auswahl.
Ich meine lisp mit eval und quote
sollte für fortgeschrittenen Programmierer dabei sein,
damit man in dieser Methodik denken lernt.
Ansonsten halte ich lisp für technisch überholt.

> aber für mich selber würde ich es bevorzugen, mich
> auf eine oder auf ganz wenige Sprachen konzentrieren zu können.

Wenn ich zwischen C und Python hin und herspringe,
versuche ich in C
if a<b: a+=1; f(a)
und in Python
if (a<b){ f(++a);}

Das ich Sprachen vollständig lerne, habe ich aufgegeben.
Und bei Laufzeitfunktionen muss ich häufig nachschlagen,
z.B. bei der Reihenfolge von Argumente.

Der Sprachumfang von Python ist erheblich höher als der
von C, aber mit einer Teilmenge davon lässt sich
einfacher etwas machen.

So habe ich erst vor wenigen Wochen den Nutzen
von set bemerkt, obwohl ich schon viel Jahre
meist Python verwendet habe.

Wenn ich ein Kurs besuche, bekomme ich viel nicht mit,
und vergesse auch viel.

>    (Aus praktischen Gründen muß ich derzeit mehr
>    Programmiersprachen [zumindest deren Grundlagen]
>    erlernen als mir eigentlich lieb ist.)

Ich sehe das so.
Eine Hauptprogrammiersprache
( meine historische Reihenfolge:
   Fortran :-| , Pascal :-(  ,  C :-) , Python :-) )
Ein Programmiersprache für große Mengen
und zeitkritische ( z.B. Grafik) Aufgaben
( bei mir C )
Sprachen die ich spezifisch verwende,
( bash für Konsole und javascript für browser)
Sprachen die ich für spezielle Anwendungen brauchen könnte
( C++, LUA, perl, php, Assembler für Arm.., mini und micro Python)
Sprachen die vielleicht etwas interessantes enthalten
( Ruby smalltatalk, ghc ..)
Sprachen  denen ich aus dem Weg gehe
( Java, Pascal.., COBOL )

Hermann
    der beruflich keine Programmiersprache mehr zu lernen braucht,
    und vermutet, das mittlerweile die meisten Bücher über Programmieren,
    die er in Buchläden sieht, von Python handeln.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#4990 — Re: [Python-de] Bitte widersprechen

Wegen der Mehrsprachigkeit:

Klar lernen die Kinder später fließen zu sprechen, aber der Unterschied ist meiner Erfahrung nach gering, und schlussendlich sprechen sie zwei Sprachen fließend, anstatt in einer nur herum zu stammeln.

Gruss


Uwe Schmitt

________________________________________
Von: python-de [python-de-bounces+uwe.schmitt=id.ethz.ch@python.org]" im Auftrag von "Stefan Ram [ram@zedat.fu-berlin.de]
Gesendet: Dienstag, 17. Oktober 2017 20:05
An: python-de@python.org
Betreff: Re: [Python-de] Bitte widersprechen

Achim Domma <domma@procoders.net> writes:
>- Learn one programming language, not ten: Du kennst "Pragmatic
>Programmer"? Da wird eine Sprache pro Jahr als Minimum empfohlen. Das
>würde ich auch so sehen. Wer nur eine oder zwei Sprachen kann, kann nur
>in diesen Strukturen denken und hat in der Regel Scheuklappen an.

  Die einen nennen es "nur in diesen Strukturen denken und
  Scheuklappen anhaben", für die anderen ist "Thinking in
  Python" und "Vermeidung von nicht-idiomatischem Programmieren"
  etwas Erstrebenswertes.

  Auch Mehrsprachigkeit hat ihre Nachteile:

      »Infants who are raised in bilingual homes learned two
      similar-sounding words in a laboratory task at a later age
      than babies who are raised in homes where only   ¯¯¯¯¯¯¯¯¯
      one language is spoken.«

www.eurekalert.org/pub_releases/2007-09/sfri-bri092407.php

  (Es könnte sein, daß diese URI von 2007 inzwischen nicht
  mehr zielführend ist.)

_______________________________________________
python-de maillist  -  python-de@python.org
https://mail.python.org/mailman/listinfo/python-de

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.python

csiph-web