Seite 1 von 1

implementation von this.py

Verfasst: Samstag 17. März 2007, 02:52
von Costi
hat es irgendein grund warum, im modul "this" (printed den zen of python aus) der zen of python selbst verschluesselt ist?

just for fun?

Verfasst: Samstag 17. März 2007, 10:52
von Joghurt
vermutlich

Verfasst: Samstag 17. März 2007, 18:52
von Leonidas
Joghurt hat geschrieben:vermutlich
Das sicher auch, aber es könnte ebenso als Proof of Concept gemeint sein, der zeigt dass man Python-Code durch die Codecs-Mechanik verändern kann.

Verfasst: Samstag 17. März 2007, 20:54
von sape
"Simple is better than complex.", ...


Code: Alles auswählen

s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print "".join([d.get(c, c) for c in s]
:wink:

Meine beschiedene Meinung: Der Code ist vielleicht ein wenig selbst ironisch gemeint. Wen man sich this.py mal anschaut verstößt es gegen einige Zens.

z.B.: Wäre "Simple is better than complex." **und** "There should be one-- and preferably only one --obvious way to do it.":

Code: Alles auswählen

print """The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!"""
...

Verfasst: Samstag 17. März 2007, 21:21
von Leonidas
sape hat geschrieben:z.B.: Wäre "Simple is better than complex." **und** "There should be one-- and preferably only one --obvious way to do it."
Although that way may not be obvious at first unless you're Dutch. :P

(Wenn wir uns schon an jeden Buchstaben des Zens streng halten müssen.)

(Zum Glück müssen wir das nicht.)

Verfasst: Samstag 17. März 2007, 21:24
von tiax

Code: Alles auswählen

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print "".join([d.get(c, c) for c in s])
Hui!

Code: Alles auswählen

text.decode('rot13')

Verfasst: Samstag 17. März 2007, 22:08
von BlackJack
Das ZEN gibt's AFAIK schon länger als die Möglichkeit 'rot-13' als Kodierung anzugeben.

Und Tim Peters ist kein Holländer, also zählt das Argument nicht. :-)

Verfasst: Samstag 17. März 2007, 22:17
von Leonidas
BlackJack hat geschrieben:Das ZEN gibt's AFAIK schon länger als die Möglichkeit 'rot-13' als Kodierung anzugeben.
Ja, ich habe grad this.py untersucht und eigentlich kann man es inzwischen anders schreiben: unthis.py.

Verfasst: Sonntag 18. März 2007, 20:41
von sape
Hat ein wenig Ähnlichkeit mit Armins Code: http://www.active-4.com/blog/archives/entry-20.html

Verfasst: Sonntag 18. März 2007, 22:34
von Leonidas
sape hat geschrieben:Hat ein wenig Ähnlichkeit mit Armins Code
Stimmt. Allerdings encoded rot13 keine Stings automatisch, das fand ich schon bei meiner Lösung interessant.

Überhaupt ist die Coding-Maschinerie eine ziemlich mächtige Sache. Mir kreist im Kopf grade die Idee rum, dass man PyLit auch als Codec implementieren könnte und somit Literate Python mit Transparenter Umwandung schrieben könnte. Ich glaube das werde ich mal dem Autor schreiben. Auch wenn die Codecs gar nicht für sowas gedacht sind.

Verfasst: Sonntag 18. März 2007, 22:39
von Joghurt
Leonidas hat geschrieben:Auch wenn die Codecs gar nicht für sowas gedacht sind.
Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommen ;)

Verfasst: Sonntag 18. März 2007, 22:44
von Leonidas
Joghurt hat geschrieben:
Leonidas hat geschrieben:Auch wenn die Codecs gar nicht für sowas gedacht sind.
Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommen ;)
Stimmt. Aber es wäre sicherlich etwas, was man mal ausprobieren könnte. Haskell bietet mit den lhs-Dateien so etwas schon nativ an. Es ist immer interessant, welche Verrenkungen man mit Python hinbekommen kann (Lisp, anyone?). Auch wenn das nicht unbedingt praxistauglich ist.

Verfasst: Montag 19. März 2007, 10:32
von Joghurt
Ja, Just for fun ist das ok. Aber generell:
The Zen Of Python hat geschrieben:There should be one-- and preferably only one --obvious way to do it.

Verfasst: Montag 19. März 2007, 21:04
von sape
Leonidas hat geschrieben:[...]Mir kreist im Kopf grade die Idee rum, dass man PyLit auch als Codec implementieren könnte und somit Literate Python mit Transparenter Umwandung schrieben könnte. Ich glaube das werde ich mal dem Autor schreiben. Auch wenn die Codecs gar nicht für sowas gedacht sind.
Meinst du das dann automatisch sowas erzeugt wird? http://pylit.berlios.de/tutorial/index.html -- Die Idee würde ich gut finden.

Verfasst: Montag 19. März 2007, 21:45
von mq
Joghurt hat geschrieben:Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommen ;)
Och, ich hatte mal die Idee, auf dem Weg etwas Lingua::Romana::Perligata-aehnliches fuer Python zu implementieren :D
Im Endeffekt hab ich's aber doch wieder verworfen, zu viel Aufwand fuer etwas, das eh niemand benutzt.

Verfasst: Montag 19. März 2007, 22:04
von Leonidas
lumax hat geschrieben:Och, ich hatte mal die Idee, auf dem Weg etwas Lingua::Romana::Perligata-aehnliches fuer Python zu implementieren :D
Ich habe ja mal einen Piglatin-Codec geschrieben (bis auf das er grauenhaft schlecht ist, funktioniert er sogar). Den könnte man vielleicht sogar auf Python-Code laufen lassen, aber das endet sicherlich in einem Fiasko.

@sape: Ja. Man schriebt diesen Literate-Code (also den der in den Beispielen in txt-Dateien gespeichert wird), gibt in der Coding-Zeile das Encoding "literate" an und lässt den Codec dann den Code umwandeln - so wie in Mitsuhikos oder meiner this.py - nur geringfügig sinnvoller. Ob das ein interessantes Konzept ist, welches man weiterverfolgen kann - darüber lässt sich streiten, aber so einen Codec zu implementieren ist ziemlich simpel, wenn man von meinem Piglatin-Codec ausgeht und dort einfach PyLit verwendet. Allerdings bin ich bisher leiter nicht dazu gekommen PyLit auszutesten, da ich mit TRE kaum weiterkomme, was mich ein wenig ärgert.

Verfasst: Montag 19. März 2007, 22:09
von sape
Hi Leonidas.

Das hört sich interessant an. Leider kenne ich mich mit PyLit nicht aus und habe auch momentan kleine Zeit um das zu testen, sonst würde ich mich mal ran setzen. Aber falls du mal was in der Richtung machst, halte uns auf den laufenden :D Ich werde mal bei Gelegenheit PyLint auch mal ansehen und mal testen.

BTW: Was ist TRE?

Verfasst: Montag 19. März 2007, 22:18
von Leonidas
sape hat geschrieben:Aber falls du mal was in der Richtung machst, halte uns auf den laufenden :D
Klar, gerne.
sape hat geschrieben:BTW: Was ist TRE?
Eine interessante Regex-Engine die ich versuche über ctypes einzubinden. Siehe diesen Thread - wenn du etwas beisteuern willst/kannst, ist dein Code natürlich höchst willkommen.

Verfasst: Montag 19. März 2007, 22:36
von BlackJack
Python auf "deutsch" gibt's von einem Autor, der ein Package geschrieben hat, das es einfacher machen soll Python um eigene Syntaxkonstrukte zu erweitern. Das Projekt heisst Easy Extend. Dort dann links auf "Teuton" klicken. (Frames sind doof)

Das sollte sich leicht auf andere Sprachen wie zum Beispiel Latein umsetzen lassen.

Verfasst: Montag 19. März 2007, 23:02
von Leonidas
BlackJack hat geschrieben:Dort dann links auf "Teuton" klicken. (Frames sind doof)
Irgendwie ist das lustig, ja (außer dass man ``from`` mit ``aus`` übersetzen sollte).