Keine Konstanten in Python: warum?

[lunar]

@fredistdurstig: Funktionaler Stil ist in Python eine Frage des Geschmacks. Manches lässt sich funktional sehr schön lösen, anderes dagegen ist eher umständlich. In jedem Fall ist Python nun mal keine funktionale, sondern eine imperative Sprache, die Annahme, man müsse funktionalen Stil fördern, daher nicht richtig.

Dazumal ist Python eine dynamische Sprache, die noch dazu Konvention über Regeln stellt. Deswegen gibt es keinen harten Zugriffsschutz, sondern nur Unterstriche, und deswegen gibt es keine Konstanten. Das ist nicht „pythonisch“.

Davon abgesehen, wenn Du einen Wert nicht ändern möchtest, dann hindert Dich auch nichts daran, es nicht zu tun Du bist der Programmierer.

Im Übrigen würde ich gerne wissen, was Dich zur Annahme verleitet, die Implementierung von Konstanten brächte keinen zusätzlichen Aufwand. In Anbetracht des dynamischen Laufzeitmodells ist das nämlich ziemlicher Blödsinn. Man müsste wahrscheinlich durchaus viel Aufwand treiben, um Namensräume mit unveränderlichen Elementen auszustatten, mehr als es den Nutzen wert wäre.

[Leonidas]

Anscheinend ist funktionales Programmieren in Python kein großes Thema?

Nicht so sehr wie in Scala, aber die viele der aktivsten Poster hier im Forum gehören zum funktionalen Mob von daher würde ich sagen generell eher nicht, hier im kleinen ist funktionale Programmierung in Python durchaus populär.

(Die entsprechenden Smileys sind an den entsprechenden Stellen zu plazieren und werden als Übungsaufgabe dem Leser überlassen)

[BlackJack]

@Leonidas: Funktionaler Mob ist witzig. Überlege mir das auf ein T-Shirt zu drucken. Ist noch besser als "Pythopat", weil unverständlicher und "nerdiger".

[Leonidas]

Funktionaler Mob ist witzig. Überlege mir das auf ein T-Shirt zu drucken.

Hmm, eigentlich eine coole Idee, also wenn da jemand Designvorschläge hat...

[LanX]

Also vielleicht hilfts...

in Perl sind Konstanten intern nix anderes als sogenannte "inline subs" sprich Prozeduren die nur einen konstaten Wert zurückgeben, weswegen vom Compiler der Aufruf wegoptimiert wird und direkt der Wert in den Bytecode kommt.

Perl verlangt auch keine Klammern um Funktionen auszuwerten.

Code: Alles auswählen

>>> def CONST():
...  return 4
... 
>>> CONST()
4
>>> CONST()=5
  File "<stdin>", line 1
SyntaxError: can't assign to function call

vielleicht bekommt ihrs auf der Grundlage ja "hübsch" hin... wenn die Klammern nicht stören sollte es ein Workaround sein.

PS: natürlich kann Ruby Konstanten ist ja nur ein Perldialekt mit Smalltalk OO! xD

UPDATE: Ok vergesst es in python könnte man ja jederzeit versehentlich die () vergessen und sowas wie

Code: Alles auswählen

CONST=5 

schreiben...

[Darii]

Das man Konstanten in Python "nachprogrammieren" kann war mir schon klar. Mich wundert nur, dass das so nicht in der Sprache vorhanden ist, da es ja keinen weiteren Aufwand bedeutet hätte. Daher muss es ja auch einen ganz konkreten Grund geben, warum auf Konstanten ganz explizit verzichtet wurde.

Wie sma schon erklärt hat hätte es eben doch einen zusätzlichen Aufwand bedeutet, da das Laufzeitmodell auf Veränderungen ausgelegt ist. Jede Konstante müsste also zur Laufzeit extra forciert werden oder das Objektmodell müsste zweigeteilt werden(konstante Objekte vs. normale Objekte). Es reicht ja nicht einfach eine Variable read-only zu machen. Man muss ja auch sicherstellen, dass das Objekt selbst nicht verändert werden kann. Sonst hat man trotzdem Seiteneffekte. Was bei Ruby-„Konstanten“ übrigens nicht der Fall ist.

[sma]

Mein Rant bzgl. Typdeklarationen bezog sich nicht (nur) auf "final" sondern allgemein auf Dinge wie `private static final Map<String, List<Person>> f = new HashMap<String, List<Person>>(42);`. Des weiteren möchte ich klarstellen, dass es nicht so sehr um das Schreiben, wie denn um das Lesen geht. Überall in den Java-Code ein "final" gesprenkelt zu bekommen, macht das Zeug nicht lesbarer.

Ich glaube, dem funktionalen Aussage wurde nicht widersprochen, weil er von vielen geteilt wird. Wir ticken hier ja meist so, dass kein Widerspruch Zustimmung bedeutet und diese selten explizit gemacht wird, obwohl wahrscheinlich die meisten schon auch nach positivem Feedback gieren.

Python ist IMHO einfach sehr pragmatisch, was diese Idee, ich muss von Programmierer vor sich selbst (und seinen Kollegen) schützen angeht. Unbestritten kann es praktisch sein, gewissen Konventionen von einem Werkzeug erzwingen zu wollen, aber der Python-Interpreter kann das nun einmal nicht leisten und so muss man sich eben selbst an die Regeln halten. Man kann dennoch auf die selbe Art und Weise programmieren - man wird nur nicht gezwungen.

Wenn ich deine Variablen nun mal nicht als Konstanten respektiere (und hoffentlich einen guten Grund habe), dann kann ich sie doch ändern.

Stefan

[LanX]

Wenn ich deine Variablen nun mal nicht als Konstanten respektiere (und hoffentlich einen guten Grund habe), dann kann ich sie doch ändern.

Theoretisch ja, praktisch wundert man sich mit was für DAUs (ähm User=Programmer) man es in größeren Projekten zu tun bekommt.

Die Möglichkeit eine Variable explizit als read-only zu setzen erspart einiges an nerven, die man bräuchte um eine Konvention wie "großgeschriebene Variablen sind Konstanten" durchzusetzen.

Sonst debugt man letztendlich ne Woche um rauszubekommen dass der neueste Billigeinkauf des Chefs "total unkonventionellen total produktiven Code" beigesteuert hat...

[cofi]

Sonst debugt man letztendlich ne Woche um rauszubekommen dass der neueste Billigeinkauf des Chefs "total unkonventionellen total produktiven Code" beigesteuert hat...

Davor retten einen aber keine Konstanten oder sonstiger Bondage, sondern nur ein Briefing.

[DasIch]

@LanX Wenn du ein soziales Problem hast hilft dir statische Typisierung auch nicht sonderlich, mal abgesehen davon dass die in Java auch unschön gelöst ist, Haskell macht dass besser.

[Leonidas]

@LanX Wenn du ein soziales Problem hast hilft dir statische Typisierung auch nicht sonderlich, mal abgesehen davon dass die in Java auch unschön gelöst ist, Haskell macht dass besser.

Ja, Haskell verhindert solcherlei Billigeinkäufe, weil es keine Haskell-Programmierer im Discounter gibt Abgesehen davon stimme ich natürlich zu, das auch Konstanten nicht vor Inkompetenz schützen.

[LanX]

Davor retten einen aber keine Konstanten oder sonstiger Bondage, sondern nur ein Briefing.

Wenn du ein soziales Problem hast hilft dir statische Typisierung auch nicht sonderlich,

lach ... erzählt mal dem Kunden dass er oder sein neuer Interner ne Pfeife ist... da kann man laaaaange Briefen!

Ich möchte da keine Geschichten auspacken was die Banken um 2000 rum alles eingestellt haben...

wie auch immer python hat doch bestimmt eine Möglichkeit einen schreibenden Zugriff abzufangen "setattr" oder so (perl hätte es)... das dürfte bei dieser Qualität von Kollegen locker ausreichen um sie zu "bremsen"

(von statisch hab ich nix gesagt)

[Hyperion]

wie auch immer python hat doch bestimmt eine Möglichkeit einen schreibenden Zugriff abzufangen "setattr" oder so (perl hätte es)...

Da wären wohl properties der richtige Weg. Allerdings würde das "Abfangen" den Sinn davon doch verfälschen...

[jbs]

Leztendlich hat man doch immer die Möglichkeit, den Wert zu verändern.

Und wenn ein Kunde den Code ändert, dann muss er auch mit den Konsequenzen rechnen.

[derdon]

Und wenn ein Kunde den Code ändert, dann muss er auch mit den Konsequenzen rechnen.

Er wird sich sogar Konsequenzen wünschen, wenn er am Code etwas ändert

[jbs]

ich glaube ich wollte `leben` schreiben

[LanX]

Leztendlich hat man doch immer die Möglichkeit, den Wert zu verändern.

Es ist ein Unterschied ob ne Knarre geladen auf dem Tisch liegt oder im gesichert im Schrank. Klar letztendlich gibts immer ne Möglichkeit den besten Safe zu knacken

aber jeder Idiot kann CONST=42 eintippen, im Zweifelsfall bin ich nach einem 12h Tag selbst der Idiot.

Und wenn ein Kunde den Code ändert, dann muss er auch mit den Konsequenzen rechnen.

Klar, aber kalkuliere den Aufwand ein um erstens die Fehlerquelle zu orten und zwotens deinem Kunden das Unvermögen eines seiner Angestellten dann diplomatisch zu verklickern und all dies nach dem er dir eine Woche lang auf die Pelle gerückt ist.

Kunden kaufen nicht die langfristig besten Entwickler ein, sondern diejenigen die sie kurzfristig am glücklichsten machen.

Denk dran Dilbert wird schon lange nach Geschichten aus Leserbriefen gestaltet...