Warum funktioniert max() auf Listen mit Strings nicht ?

[Mad-Marty]

@modelnine :

Das war doch nur ein mini-stückchen des ganzen moduls ....
Da sind noch unmengen von klassen wo der speed wichtig wird.


@ Blackjack:

Stimmt, jetzt wo ich nochmal auf den source sehe ....
Ohje ^^, sollte sowas nicht nebenbei probieren ...

[modelnine]

Auserdem kann man eine erweiterung viel besser verteilen als 30 kleine py files ... und es kann niemand mehr was verfrickeln.

<rant>

Du denkst genau wie alle Closed-Source-Programmierer da draußen, dass nämlich andere Programmierer vom Inhalt eines Programms so gut wie nur möglich abzuschotten sind. Das ist natürlich möglich, indem ich nur eine kompilierte C-Erweiterung ausliefere.

Hat das Sinn? Auch wenn es mir widerstrebt mit ESR einer Meinung zu sein: "Nein!"

Denn: Pythons Offenheit ist dafür gedacht, dass ich als Benutzer Deiner libs gucken kann wie sie funktionieren, und wenn ich den Quellcode ausgeliefert bekomme kann ich selbst dran rumbasteln um sie in Ordnung zu bringen. Dass Du mir keinen Support dafür lieferst wenn ich sie kaputt-daddele ist mir klar, nur hab ich so wenigstens die Möglichkeit Fehler die Du möglicherweise gemacht hast zu korrigieren, und Dein Produkt sinnvoll einzusetzen.

Kleines Beispiel zwischendrin: die xmlrpclib hat einen leichten Defekt, dass es nämlich nicht möglich ist mit https-servern xmlrpc-Verbindungen aufzubauen, zumindest nicht so wie ich das will. Ich sehe den Quellcode, kann mir eine eigene xmlrpclib.ServerProxy-Klasse ableiten, und da die benötigten Funktionen reinpatchen. Das ganze geht wunderbar, weil ich eine in Python-geschriebene Klasse erweitere, die ich zum anderen auch noch durchgucken kann.

Wenn Du das ganze als Binärpaket auslieferst (oder aber als Pyrex generierten C-File, der mindestens genauso scheiße zu ändern ist, da autogenerierter Code), dann kann ich nur sagen: "es tut nicht das was ich will, okay, schmeißen wir es weg und schreiben es neu."

Source-Code-Obfuscation ist das beschisstenste auf der Welt. Und wenn Du jetzt schon anfängst nur zur Liebe der Obfuscation eine Routine die _nicht_ performancekritisch, _nicht_ innovativ, eher noch trivial ist, in Pyrex (also C) zu implementieren damit Du Deine Benutzer vor Ihnen selbst schützt, dann bist Du nicht besser als die ganzen Musikkonzerne da draußen die Ihre CDs mit Kopierschutz ausstatten weil sie davon ausgehen dass Ihre Kunden sie bescheißen.

Nix mehr mit "im Zweifel für den Angeklagten," sondern "der Angeklagte ist schuldig, beweise er seine Unschuld."

Und woher Du die Idee bekommst dass es schwierig ist 30 .py-Files auszuliefern versteh ich nicht... Es gibt erstens schon lange Archiv-Formate wie .tar, .zip, .arc, .lha, .7z, ..., und zum andere hat Python eine fantastische Erweiterung mit Namen distutils, die Dir die Installation und Verteilung von 30 .py-Files sowas von einfach macht dass es echt nicht nachzuvollziehen ist.

Und: wenn Du wirklich Geschwindigkeit rausholen willst: schreib direkt eine C-Erweiterung für deinen Spezialfall, kein "allgemeines" Pyrex. Das ist wirklich einfach nur obfuscation (in den meißten Fällen, ich sag nicht dass es auch ausnahmen gibt).

</rant>

--- Heiko.

[jens]

Wo liegt denn das Problem... Mit rot13 kann man doch prima den Python-Code verschlüsseln: http://www.python-forum.de/viewtopic.php?t=4953