implementation von this.py
Verfasst: Samstag 17. März 2007, 02:52
hat es irgendein grund warum, im modul "this" (printed den zen of python aus) der zen of python selbst verschluesselt ist?
just for fun?
just for fun?
Seit 2002 Diskussionen rund um die Programmiersprache Python
https://www.python-forum.de/
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.Joghurt hat geschrieben:vermutlich
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]
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!"""
Although that way may not be obvious at first unless you're Dutch.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."
Hui!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])
Code: Alles auswählen
text.decode('rot13')
Ja, ich habe grad this.py untersucht und eigentlich kann man es inzwischen anders schreiben: unthis.py.BlackJack hat geschrieben:Das ZEN gibt's AFAIK schon länger als die Möglichkeit 'rot-13' als Kodierung anzugeben.
Stimmt. Allerdings encoded rot13 keine Stings automatisch, das fand ich schon bei meiner Lösung interessant.sape hat geschrieben:Hat ein wenig Ähnlichkeit mit Armins Code
Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommenLeonidas hat geschrieben:Auch wenn die Codecs gar nicht für sowas gedacht sind.
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.Joghurt hat geschrieben:Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommenLeonidas hat geschrieben:Auch wenn die Codecs gar nicht für sowas gedacht sind.
The Zen Of Python hat geschrieben:There should be one-- and preferably only one --obvious way to do it.
Meinst du das dann automatisch sowas erzeugt wird? http://pylit.berlios.de/tutorial/index.html -- Die Idee würde ich gut finden.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.
Och, ich hatte mal die Idee, auf dem Weg etwas Lingua::Romana::Perligata-aehnliches fuer Python zu implementierenJoghurt hat geschrieben:Eben. Vielleicht sollte man es auch dabei belassen, sonst sind wir bald bei Perl angekommen
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.lumax hat geschrieben:Och, ich hatte mal die Idee, auf dem Weg etwas Lingua::Romana::Perligata-aehnliches fuer Python zu implementieren
Klar, gerne.sape hat geschrieben:Aber falls du mal was in der Richtung machst, halte uns auf den laufenden
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.sape hat geschrieben:BTW: Was ist TRE?
Irgendwie ist das lustig, ja (außer dass man ``from`` mit ``aus`` übersetzen sollte).BlackJack hat geschrieben:Dort dann links auf "Teuton" klicken. (Frames sind doof)