Python wird immer komplizierter

[BlackVivi]

Statt ``make install`` sollte man besser ``make altinstall`` verwenden, sonst überschreibt man sich am Ende die bereits bestehende Python-Installation.

Daher habe ich bei ``./configure`` ja auch ein Prefix angegeben. Es gab sogar irgendwo ein Linux, welches wie Windows alles in eigene Programmordner installiert hat. Mir fällt der Name aber nicht mehr ein.

GoboLinux oO?

[Erwin]

Einerseits kommt man auf lange Sicht bei Computern und Programmiersprachen nicht um Veränderungen herum. Wenn ich an die ganzen Zeilen Assembler auf dem C64 denke…

Also ich lernte damals in der Schule Informatik auf einen C64.
Die Sprache war aber Basic. *g*

Wenn ich an GFA-Basic denke ... .
Damals, am Atari ST, hatte ich mich gegen GFA-Basic für Omikron-Basic entschieden.
Und das deshalb, weil mir Omikron vertrauter vor kam. Eben mit Nummerirung und so.
Ich hätte GFA nehmen sollen. Das war laut meiner Erinnerung an dessen Beschreibung ein Vorläufer oder sogar bereits eine Objektorientierte Programmiersprache.

Fehlende deutsche Dokumentation, in der ich die Gründe so wie auch die weiter laufende Ziele, nachvollziehen könnte, scheint es wohl leider auch nicht zu geben.
Das würde aber vermutlich zu mehr Akzeptanz führen, dass ich später umlernen muss, obwohl ich die Sprache derzeit als verdammt gut empfinde.

[sma]

GFA-Basic würde ich definitiv nicht als objektorientiert bezeichnen. Die erste Mainstream-Sprache, der ich dieses Attribut geben würde war TurboPascal 5.5, und das kam später. Tatsächlich war GFA-Basic eher ein Pascal-Dialekt denn ein klassisches Basic - und der Grund, warum ich mir damals einen Atari kaufte... ;)

Stefan

PS: Signum war natürlich auch cool...

[Erwin]

GFA-Basic würde ich definitiv nicht als objektorientiert bezeichnen. Die erste Mainstream-Sprache, der ich dieses Attribut geben würde war TurboPascal 5.5, und das kam später. Tatsächlich war GFA-Basic eher ein Pascal-Dialekt denn ein klassisches Basic - und der Grund, warum ich mir damals einen Atari kaufte...

Und bei mir war es umgekehrt:
Weil das fehlen von Zeilen-Zahlen, Goto per Name (?) und noch irgendwas mich gar nicht an Basic erinnerte, nahm ich dann Omikron.
Denn das neu lernen, nach dem ich schon etwas Basic konnte, wollte mir halt gar nicht gefallen.

[Leonidas]

GoboLinux oO?

Bingo, das wars. Lustige Sache eigentlich. Man wünscht sich fast noch /A, /C, /D etc

Fehlende deutsche Dokumentation, in der ich die Gründe so wie auch die weiter laufende Ziele, nachvollziehen könnte, scheint es wohl leider auch nicht zu geben.
Das würde aber vermutlich zu mehr Akzeptanz führen, dass ich später umlernen muss, obwohl ich die Sprache derzeit als verdammt gut empfinde.

Sprichst du nun von Basic oder Python? Der Kontext sagt Basic, die Logik sagt Python.

Und wenn Python, dann stimmt die Logik nicht einmal. Es gibt nämlich ausgiebig Dokumentation auf Deutsch für Python einschließlich eines Buches, was in der Letzten Zeit aggressiv überall beworben und es nicht besser macht (BlackVivi, danke für die kritische Bemerkung auf Pro-Linux *g*). Aber es gibt auch gute Deutschsprachige Lektüre. Und Python 3.0 wird gar nicht so viel umlernen sein, es wird eher wie ein Schritt von 2.4 auf 2.5 sein, nur dass da Sachen dabei sein werden, die alten Quellcode nicht mehr vorwährtskompatibel lassen. Aber alles in allem wird Python 3.0 eben hauptsächlich ein saubereres, vereinfachtes Python 2.x. Einige hätten sich da mehr erwartet.

[Erwin]

Sprichst du nun von Basic oder Python? Der Kontext sagt Basic, die Logik sagt Python.

Stimmt, der Kontext sagt Basic.
Sorry, da habe ich nicht aufgepasst. Da ging ich zu schnell von einem in das andere über.

Und wenn Python, dann stimmt die Logik nicht einmal. Es gibt nämlich ausgiebig Dokumentation auf Deutsch für Python einschließlich eines Buches, was in der Letzten Zeit aggressiv überall beworben und es nicht besser macht (BlackVivi, danke für die kritische Bemerkung auf Pro-Linux *g*). Aber es gibt auch gute Deutschsprachige Lektüre. Und Python 3.0 wird gar nicht so viel umlernen sein, es wird eher wie ein Schritt von 2.4 auf 2.5 sein, nur dass da Sachen dabei sein werden, die alten Quellcode nicht mehr vorwährtskompatibel lassen. Aber alles in allem wird Python 3.0 eben hauptsächlich ein saubereres, vereinfachtes Python 2.x. Einige hätten sich da mehr erwartet.

Das mit dem Buch, und nicht besser macht, beschreibt Er das Ganze etwa schlecht?
Werde dann mal in der Buchhandlung nachfragen, ob die da was haben.
Daran hatte ich jetzt gar nicht so recht gedacht.

[Leonidas]

Das mit dem Buch, und nicht besser macht, beschreibt Er das Ganze etwa schlecht?
Werde dann mal in der Buchhandlung nachfragen, ob die da was haben.
Daran hatte ich jetzt gar nicht so recht gedacht.

Das Buch ist insofern schlecht, dass der Autor mehrere Fehler macht, teilweise auch ganz blöde und außerdem ist das Kapitel über Objektorientierung realitätsfremd.

Gute deutsche (übersetzte) Einführungstexte sind Wie ein Informatiker denken lernen... mit Python (nicht ganz fertig) und A Byte of Python.

[Erwin]

Byte of Python kenne ich. Die Übersetzung.
Ist irgendwie ... also mir hat es zwar gefallen.
Aber fraglich ob jedem es so kurz und bündig zu sagt?
Auch wird nur ein Teil darin behandelt, finde ich.
Aber gelesen haben sollte man es auf alle Fälle mal, finde ich.
Und das wo es auch noch umsonst ist.

In der Buchhandlung konnte man mir leider nicht weiterhelfen.
Viele über Python 2.5, (3 davon auf Lager und über 30 Euro), aber leider keins über 3.0 (auch nicht im Computer).

Denke werde trotzdem erst mit 2.5 weiter machen, und mich um 3.0 erst später kümmern.
Sonst bin ich vielleicht doch wieder viel zu sehr hin und her gerissen.
Außerdem könnte es ja sein, dass je weiter ich mich in die Materie rein arbeite, mir die Umstellung dann einfacher fällt und auch Nachvollziehbarer ist.

[BlackJack]

Woher kommt dieses übermässige Interesse an der 3.0? Die gibt's noch nicht wirklich. Die Alpha-Version ist immer noch ein wenig im Fluss was die Details angeht, da kann man noch gar kein Buch drüber schreiben. "Dazwischen" wird es auf jeden Fall eine Version 2.6 geben, die wie schon gesagt, ein wesentlich besser "Absprungpunkt" zur 3.0 sein wird.

Ich würde empfehlen weiter für die aktuelle Version zu programmieren, dann auf die 2.6 umzusteigen und darauf zu vertrauen dass das 2to3-Skript gute Arbeit leistet. Bis dahin sollte man Unittests schreiben, um den Quelltext nach dem Umstieg zu überprüfen und sich auf jeden Fall mit Unicode auseinander zu setzen.

Wenn Du *dann* fragen hast, sind wir hier ja immer noch da.

[Leonidas]

In der Buchhandlung konnte man mir leider nicht weiterhelfen.
Viele über Python 2.5, (3 davon auf Lager und über 30 Euro), aber leider keins über 3.0 (auch nicht im Computer).

Wie BlackJack schon sagte - 3.0 interessiert zum gegenwärtigen Zeitpunkt noch überhaupt nicht.
Die einzige Dokumentation dazu ist die offizielle 3.0-Dokumentation und auch diese ist auch nicht immer up-to-date.

Wenn 3.0 rauskommt werden eben die vorhandenen Bücher etwas umgeschrieben um die Syntax anzupassen, ein Kapitel über Unicode kommt dazu und das wars auch schon von dieser Seite. Python 3.0 wird keine komplett neue Sprache, die komplett neu gelernt werden muss.

[Erwin]

Woher kommt dieses übermässige Interesse an der 3.0? Die gibt's noch nicht wirklich. ...

Ich hasse 3.0.
Aber je eher man weiß, was da auf einem Zukommt, desto eher könnte ich mich darauf einstellen.
Zu mal ich bis jetzt noch nicht richtig drin bin in der Materie.
Je später, desto mehr muss ich eines Tages umlernen.
Warum kann man nicht einfach nur Fehler ausbessern?
Und meinetwegen Zusätzliche Funktionen einbauen, aber bitte so, dass halt auch altes Script in den neuen Interpreter laufen.

[BlackJack]

Ganz einfach weil es Entwurfsfehler gibt, die man einfach nicht ausbessern kann ohne das mit der Rückwärtskompatibilität gebrochen wird.

Dazu gehört zum Beispiel der ``print``-Sonderfall, mit dem "enthaltenen" ``>> datei``-Sonderfall, oder die Backticks statt `repr()` und das die Sprache mittlerweile stärker auf Generatoren setzt und es damit Sinn macht, einige Funktionen und Methoden darauf um zu stellen. Nach über 10 Jahren bzw. 8 Jahren Python 2.x ist es einfach mal nötig Altlasten aus zu misten. Wenn man immer nur hinzu fügt, sammeln sich Irrwege und alte Konstrukte, für die es neue, bessere Alternativen gibt an.

Wenn sich die Sprachen nicht weiter entwickeln würden, wären wir heute noch bei BASIC mit Zeilennummern. Da gab's ja auch den Schritt auf dem PC von GW-BASIC zu QBASIC mit einem QBASIC-Programm das Standardmässig dabei war, das Zeilennummern aus Quelltext entfernt und an den entsprechenden Stellen durch Marken ersetzt hat.

Der übliche Zyklus bei Python-Veröffentlichungen liegt bei ca. 18 Monaten. Der von der 2.5 ist noch nicht zu ende und die 2.6 ist dann auch solange aktuell. Da 2.x und 3.x länger nebeneinander gepflegt werden, als bisherige Versionen, kannst Du sicher noch mindestens 2 Jahre lang Python 2.5/2.6 verwenden ohne Dir grosse Gedanken um die 3.0 machen zu müssen. Bei Ubuntu kann man auch immer noch die vorletzte Python-Version per Paketverwaltung installieren.

[Erwin]

Wenn sich die Sprachen nicht weiter entwickeln würden, wären wir heute noch bei BASIC mit Zeilennummern. Da gab's ja auch den Schritt auf dem PC von GW-BASIC zu QBASIC mit einem QBASIC-Programm das Standardmässig dabei war, das Zeilennummern aus Quelltext entfernt und an den entsprechenden Stellen durch Marken ersetzt hat.

Der Vergleich hinkt ein wenig.
Wenn Jemand mit Basic programmieren will, egal warum (ist dem sei Sach), dann will er es halt. Hat auch irgendwo seinen Reiz, finde ich.
Und auch in gewissen Dingen einfacher.
Ich hingegen kann mit totaler Objekt-Orientierter Sprachen, wie Delhi 2 und 3, gar nichts so recht anfagen.
Python scheint für mich die richtige Mitte zu sein.
Und auch leicht verständlich.
Und hoffentlich bleibt die auch in der Mitte.

Ich wollte zwar ausführlicher schreiben, aber Du hast gefragt, ich habe geantwortet.
Will aber nicht mehr weiter darauf Antworten.

Weil Gründe könnte ich viele nennen und ausführlicher erklären.
Für Dich vermutlich unbedeutend, für mich leider nicht.
Will diese daher bei Seite schieben, und nicht neu aufwühlen.
Je mehr ich versuche, Dir die Fragen zu beantworten, desto mehr wirken die Bedenken wieder auf mich ein.
Ist halt wie mit den Grünen Elefanten.
Ich hatte kurz die Kurve, jetzt habe ich wieder bedenken, durch die Überlegung, wie ich es Dir meinen Standpunkt erklären soll.
Die will ich nicht weite nähren, in dem ich wieder alles herauf hole.

[birkenfeld]

Keine Sorge, Python 3 wird seinen Character nicht ändern. Wir bleiben ja auch letztendlich dieselben, auch wenn wir altern und uns (hoffentlich zum besseren) entwickeln.

[Leonidas]

Wenn Jemand mit Basic programmieren will, egal warum (ist dem sei Sach), dann will er es halt. Hat auch irgendwo seinen Reiz, finde ich.

Das gleiche wird auch für Python 2.x gelten - du wirst es auch noch in in in vielen Jahren nutzen können. Das ist so, wie wenn man Python 1.5 rauskramt oder gar ältere Versionen und damit versucht was zu Programmieren - es geht, aber inzwischen ist alles einfacher

Ich hingegen kann mit totaler Objekt-Orientierter Sprachen, wie Delhi 2 und 3, gar nichts so recht anfagen.
Python scheint für mich die richtige Mitte zu sein.

Will dich ja nicht verschrecken, aber Python ist "total Objekt-Orientierter" als Delphi.

[Erwin]

Will dich ja nicht verschrecken, aber Python ist "total Objekt-Orientierter" als Delphi.

Damit verschreckst Du mich nicht.
Weil ich bei Python Dinge machen konnte, was ich bei Delphi 2 nicht ohne weiteres auf die Reihe brachte.
z.B.:

Code: Alles auswählen

a = 1
b = 2
print a+b

Was für mich vom Machbarem her einen Art Grundcharakter von Basic für mich hat.
So weit ich mich noch erinnere, musste ich unter Delphi 2 dafür extra einen Button zweckentfremden, nur um 2 Dinge einfach zusammen zählen zu lassen.
Zumindest wusste ich mir da nicht anders zu helfen.
Bzw. war mir das dann einfacher, als extra Art Objekt (oder was es auch immer war) zu schreiben, und diesen dann so wohl unten zu schreiben und oben Bescheid zu sagen, da unten ist noch was, was auch ausgeführt werden muss.
War irgendwie etwas für mich wie ohne Anfang und Ende.
Und Umständlich.
Kam damit halt nicht klar.
Aber vielleicht waren die Bücher dazu einfach auch zu sehr auf das Objektorientierte aus, und haben andere Möglichkeiten deshalb außen vor gelassen.

Da fällt mir gerade ein, eine Diplomierte Informatikerin meinte neulich zu mir, Python wäre gar nicht Objektorientiert.
Interessant was die Heute so an den Schulen lernen.

[BlackJack]

Da Delphi letztlich eine Obermenge von (Turbo)Pascal ist, könnte das Beispiel so aussehen:

Code: Alles auswählen

PROGRAM Test;

VAR a,b:Byte;

BEGIN
    a := 1;
    b := 2;
    WriteLn(a + b);
END.

Etwas mehr Schreibarbeit als in Python, weil etwas formaler und statisch typisiert, aber trotzdem noch recht übersichtlich.

Falls die Informatikerin sich Python tatsächlich mal angeschaut hat, sollte sie ihr Diplom zurückgeben.

[Erwin]

Da Delphi letztlich eine Obermenge von (Turbo)Pascal ist, könnte das Beispiel so aussehen:

Code: Alles auswählen

PROGRAM Test;

VAR a,b:Byte;

BEGIN
    a := 1;
    b := 2;
    WriteLn(a + b);
END.

Etwas mehr Schreibarbeit als in Python, weil etwas formaler und statisch typisiert, aber trotzdem noch recht übersichtlich.

Falls die Informatikerin sich Python tatsächlich mal angeschaut hat, sollte sie ihr Diplom zurückgeben.

Nein nein, so einfach ging das nicht, so weit ich weiß.
Weil der hatte ja einen Art Kopf, wo erst mal alle Objekte aufgelistet wurde.
Dann kamen die Vars, glaube ich.
Danach dann:
BEGIN ObjecktXY(bla,bla,bla):
a := 1;
b := 2;
WriteLn(a + b); # schon gar nicht. Denn wo soll er es hinschreiben?
END.

Also für mich extrem wirwar.

[BlackJack]

`WriteLn()` schreibt auf die Standardausgabe, genau wie ``print`` in Python.

[Erwin]

`WriteLn()` schreibt auf die Standardausgabe, genau wie ``print`` in Python.

Dem muss man dann mitteilen, ob der Text dann auf dem Button stehen soll, oder Label, oder Editor, oder Überschrift.
Sonst wird das bei Delphi 2-3 nichts.
So was wie eine Standardausgabe gibt es nicht.
Der ganze Quelltext wird dort Kompiliert, zu exe verarbeitet, und dann läuft das Programm.