Vermutlich habe ich irgendwas falsch verstanden, wie unpacking funktioniert. Jedenfalls: zahlen = [[5,5,5]] zahlen.append([9,9,9]) for t in zahlen: t[1] += t[2] nummern = [[5,5,5]] nummern.append([9,9,9]) for a,b,c in nummern: b += c Auf der Konsole dann abgefragt: zahlen Out[7]: [[5, 10, 5], [9, 18, 9]] nummern Out[8]: [[5, 5, 5], [9, 9, 9]] Ich kapier das nicht. Funktioniert unpacking nur lesend? Oder wie kann ich einen Wert während der For-Schlaufe ändern, ohne die umständliche Notation zu verwenden? Grüsse Patrick
On 2024-08-06 20:57, Patrick Rudin <taxi_bs@gmx.ch> wrote:
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: b += c
nummern Out[8]: [[5, 5, 5], [9, 9, 9]]
Ich kapier das nicht. Funktioniert unpacking nur lesend?
Nein, aber int ist ein Immutable-Typ. Du kannst den Wert eines int-Objekts nicht ändern.
for a,b,c in nummern: b += c
Beim ersten Schleifendurchlaut zeigt b tatsächlich auf das selbe int-Objekt wie nummern[0][1] und c auf das selbe int-Objekt wie nummern[0][2]. (Tatsächlich zeigen sie sogar auf das selbe Objekt). b += c macht zwei Dinge: 1) Es ruft b.__iadd(c) auf. Wenn b mutable wäre, würde das den Wert des Objekts, auf das b zeigt ändern und das Objekt zurückliefern. Da das Objekt aber immutable ist, kann sein Wert nicht geändert werden. Es wird also ein neues Objekt (vom Typ int mit dem Wert 10) erzeugt und zurückgeliefert. 2) Der Returwert wird an b zugewiesen. b zeigt also jetzt auf das neue Objekt. nummern[0][1] zeigt aber immer noch auf das alten, denn dem hast Du ja kein neues zugewiesen.
Oder wie kann ich einen Wert während der For-Schlaufe ändern, ohne die umständliche Notation zu verwenden?
Es gibt mehrere Möglichkeiten. Wenn Du nummern in-place ändern willst, musst Du wohl die Indizes verwenden. Aber Du könntest auch eine List-Comprehension nehmen: nummern = [[a, b+c, c] for a, b, c in nummern] Das erzeugt aber eine völlig neue Liste und weist diese nummern zu. Wenn Du andere Variablen hast, die noch auch die alte Liste zeigen, dann tun sie das auch weiterhin. Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns hp
On 2024-08-06 20:57, Patrick Rudin <taxi_bs@gmx.ch> wrote:
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: b += c
nummern Out[8]: [[5, 5, 5], [9, 9, 9]]
Ich kapier das nicht. Funktioniert unpacking nur lesend?
Nein, aber int ist ein Immutable-Typ. Du kannst den Wert eines int-Objekts nicht ändern.
for a,b,c in nummern: b += c
Beim ersten Schleifendurchlaut zeigt b tatsächlich auf das selbe int-Objekt wie nummern[0][1] und c auf das selbe int-Objekt wie nummern[0][2]. (Tatsächlich zeigen sie sogar auf das selbe Objekt). b += c macht zwei Dinge: 1) Es ruft b.__iadd__(c) auf. Wenn b mutable wäre, würde das den Wert des Objekts, auf das b zeigt ändern und das Objekt zurückliefern. Da das Objekt aber immutable ist, kann sein Wert nicht geändert werden. Es wird also ein neues Objekt (vom Typ int mit dem Wert 10) erzeugt und zurückgeliefert. 2) Der Returnwert wird an b zugewiesen. b zeigt also jetzt auf das neue Objekt. nummern[0][1] zeigt aber immer noch auf das alte, denn dem hast Du ja kein neues zugewiesen.
Oder wie kann ich einen Wert während der For-Schlaufe ändern, ohne die umständliche Notation zu verwenden?
Es gibt mehrere Möglichkeiten. Wenn Du nummern in-place ändern willst, musst Du wohl die Indizes verwenden. Aber Du könntest auch eine List-Comprehension nehmen: nummern = [[a, b+c, c] for a, b, c in nummern] Das erzeugt aber eine völlig neue Liste und weist diese nummern zu. Wenn Du andere Variablen hast, die noch auch die alte Liste zeigen, dann tun sie das auch weiterhin. Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns hp
Am 06.08.24 um 22:57 schrieb Patrick Rudin über python-de:
Vermutlich habe ich irgendwas falsch verstanden, wie unpacking funktioniert. Jedenfalls:
zahlen = [[5,5,5]] zahlen.append([9,9,9])
for t in zahlen: t[1] += t[2]
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: b += c
Auf der Konsole dann abgefragt: zahlen Out[7]: [[5, 10, 5], [9, 18, 9]]
nummern Out[8]: [[5, 5, 5], [9, 9, 9]]
Ich kapier das nicht. Funktioniert unpacking nur lesend? Oder wie kann ich einen Wert während der For-Schlaufe ändern, ohne die umständliche Notation zu verwenden?
Wie schon in den anderen Antworten ausführlich erklärt, ist ein Objekt mit dem Datentyp `int` unveränderlich (immutable). Daher kann sich dessen Wert nicht ändern. Der Name `b` lässt sicher aber für neue Objekte nutzen. Alle Objekte haben eine für ihre gesamte Lebenszeit feste Kennung, eine ID. Die eingebaute Funktion `id()` gibt diese zurück. Die Ausgabe der ID für `b` vor und nach der Zuweisung mit `+=` macht deutlich, das ein neues Objekt entsteht, da `b` eine neue ID bekommt: nummern = [[5,5,5]] nummern.append([9,9,9]) for a,b,c in nummern: print('vorher: ', id(b)) b += c print('nachher:', id(b)) Ausgabe: vorher: 4375044856 nachher: 4375045016 vorher: 4375044984 nachher: 4375045272 Nach meiner Erfahrung ist so eine Anzeige von IDs eine gute Ergänzung zu grundsätzlichen Erläuterungen zum Thema Objekte und deren Veränderbarkeit. Viele Grüße Mike
Grüsse
Patrick _______________________________________________ python-de Mailingliste -- python-de@python.org Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an python-de-leave@python.org https://mail.python.org/mailman3/lists/python-de.python.org/ Mitgliedsadresse: mmueller@python-academy.de
Peter J. Holzer wrote:
On 2024-08-06 20:57, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Ich kapier das nicht. Funktioniert unpacking nur lesend?
Nein, aber int ist ein Immutable-Typ. Du kannst den Wert eines int-Objekts nicht ändern.
Oki. Hinter die Ohren geschrieben: Im Zweifelsfall immer neue Liste erzeugen.
Wenn Du nummern in-place ändern willst, musst Du wohl die Indizes verwenden.
Aber Du könntest auch eine List-Comprehension nehmen:
nummern = [[a, b+c, c] for a, b, c in nummern]
Ich hab hier rund ein Dutzend Variablen, an denen ich rumschraube. Am übersichtlichsten wäre wohl: zahlen = [[5,5,5]] zahlen.append([9,9,9]) for i, (a,b,c) in enumerate(zahlen): b += c zahlen[i] = [a,b,c] Bei vielen Variablen muss man dann halt verflucht aufpassen, dass man bei Erweiterungen die Reihenfolge peinlichst einhält. Elegant ist das nicht. Vermutlich wurden aus diesem Grund Klassen erfunden, in denen man klar und deutlich auf Attribute einzelner Instanzen zugreifen kann...
Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns
Er fängt gut an, vermischt dann aber abstrakte Syntax mit konkretem Beispiel. Da komm ich dann innerlich nicht mehr mit... Gruss Patrick
Mike Müller wrote:
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: print('vorher: ', id(b)) b += c print('nachher:', id(b))
Ausgabe:
vorher: 4375044856 nachher: 4375045016 vorher: 4375044984 nachher: 4375045272
Das hilft aber nicht weiter, weil: zahlen = [[5,5,5]] zahlen.append([9,9,9]) for t in zahlen: print('vorher: ', id(t[1])) t[1] += t[2] print('nachher:', id(t[1])) vorher: 11743656 nachher: 11743816 vorher: 11743784 nachher: 11744072 Kurzum: Auch da wird ein neues Objekt erzeugt. Gruss Patrick
Am 06.08.24 um 22:57 schrieb Patrick Rudin:
Vermutlich habe ich irgendwas falsch verstanden, wie unpacking funktioniert. Jedenfalls:
zahlen = [[5,5,5]] zahlen.append([9,9,9])
for t in zahlen: t[1] += t[2]
Die Schleife würde ich zum testen umschreiben in for t in zahlen: print(t,t[1],t[2]) t[1] += t[2] print(t,t[1],t[2])
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: b += c
Die Schleife würde ich zum testen umschreiben in for a,b,c in nummern: print(a,b,c) b += c print(a,b,c) Hermann der zum testen und analysieren meist print verwendet. -- <http://www.hermann-riemann.de>
On 2024-08-07 09:54, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
On 2024-08-06 20:57, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Ich kapier das nicht. Funktioniert unpacking nur lesend?
Nein, aber int ist ein Immutable-Typ. Du kannst den Wert eines int-Objekts nicht ändern.
Oki. Hinter die Ohren geschrieben: Im Zweifelsfall immer neue Liste erzeugen.
Ist meistens eine gute Idee, geht hier aber am Punkt vorbei. Die Liste ist ja mutable, nur die Elemente nicht. Und selbst das ist nur der Auslöser. Das Grundproblem ist, zu verstehen, was eine Zuweisung in Python macht.
Wenn Du nummern in-place ändern willst, musst Du wohl die Indizes verwenden.
Aber Du könntest auch eine List-Comprehension nehmen:
nummern = [[a, b+c, c] for a, b, c in nummern]
Ich hab hier rund ein Dutzend Variablen, an denen ich rumschraube. Am übersichtlichsten wäre wohl:
Wenn Du auf viele Variablen die gleiche (komplexe) Operation durchführst, ist es sinnvoll, diese Operation in eine Funktion auszulagern. (Wobei etwas, das man in einer Zeile schreiben kann, für mich normalerweise nicht komplex genug für eine Funktion ist.)
Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns
Er fängt gut an, vermischt dann aber abstrakte Syntax mit konkretem Beispiel. Da komm ich dann innerlich nicht mehr mit...
Um Syntax geht es in dem ganzen Talk nur sehr am Rande (ich glaube, es gibt eine Folie, wo es um Syntax geht). Wichtig ist die Semantik. Und ja, ganz abstrakt kann man das in zwei oder drei Sätzen formulieren. Das versteht dann nur keiner (außer denen, die es vorher schon verstanden haben). Die restlichen 20+ Minuten des Vortrags sind dann eben konkrete Beispiele. Deines kommt sogar fast genau so vor. hp
Peter J. Holzer wrote:
On 2024-08-07 09:54, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Ich hab hier rund ein Dutzend Variablen, an denen ich rumschraube. Am übersichtlichsten wäre wohl:
Wenn Du auf viele Variablen die gleiche (komplexe) Operation durchführst, ist es sinnvoll, diese Operation in eine Funktion auszulagern.
Anders, ich mache simples Zeug mit mehreren Variablen: http://www.mirada.ch/zuege.zip Ist einfach eine Spielerei, quasi meine ersten Gehversuche mit Python. Und ja, da sind ein paar ugly Hacks drin. Wenn ich mal Zeit habe, werde ich versuchen, sowas mit Klassen statt Listen zu machen.
Und ja, ganz abstrakt kann man das in zwei oder drei Sätzen formulieren. Das versteht dann nur keiner (außer denen, die es vorher schon verstanden haben). Die restlichen 20+ Minuten des Vortrags sind dann eben konkrete Beispiele. Deines kommt sogar fast genau so vor.
Ich werd mir das bei Gelegenheit sicher nochmals in Ruhe anschauen. Mit ein wenig Grunderfahrung geht das aber meist besser rein... Gruss Patrick
On 2024-08-07 09:57, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Mike Müller wrote:
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: print('vorher: ', id(b)) b += c print('nachher:', id(b))
Ausgabe:
vorher: 4375044856 nachher: 4375045016 vorher: 4375044984 nachher: 4375045272
Das hilft aber nicht weiter, weil:
zahlen = [[5,5,5]] zahlen.append([9,9,9])
for t in zahlen: print('vorher: ', id(t[1])) t[1] += t[2] print('nachher:', id(t[1]))
vorher: 11743656 nachher: 11743816 vorher: 11743784 nachher: 11744072
Kurzum: Auch da wird ein neues Objekt erzeugt.
Ja, aber dieses neue Objekt weist Du dem richtigen Namen zu. Wenn wir von Deinem Code mal alles weglassen, was nur verwirrt, dann bleibt übrig: t = [5, 5, 5] t[1] = t[1] + t[2] bzw. t = [5, 5, 5] a = t[0] b = t[1] c = t[2] b = b + c Ich glaube, es sollte unmittelbar klar sein, dass im zweiten Fall t[1] noch auf das alte Objekt (mit dem Wert 5) zeigt und nicht auf das neue (mit dem Wert 10). Denn dieses wird ja an b zugewiesen, und nicht an t[1], wie im ersten Fall. hp
Am 07.08.24 um 11:57 schrieb Patrick Rudin über python-de:
Mike Müller wrote:
nummern = [[5,5,5]] nummern.append([9,9,9])
for a,b,c in nummern: print('vorher: ', id(b)) b += c print('nachher:', id(b))
Ausgabe:
vorher: 4375044856 nachher: 4375045016 vorher: 4375044984 nachher: 4375045272
Das hilft aber nicht weiter, weil:
zahlen = [[5,5,5]] zahlen.append([9,9,9])
for t in zahlen: print('vorher: ', id(t[1])) t[1] += t[2] print('nachher:', id(t[1]))
vorher: 11743656 nachher: 11743816 vorher: 11743784 nachher: 11744072
Kurzum: Auch da wird ein neues Objekt erzeugt.
Und das neue Objekt kommt dann mit: t[1] += t[2] in die Liste. Aufgelöst in zwei Zeilen ist da vielleicht verständlicher: b += t[2] t[1] = b Der Name `b` ist natürlich frei wählbar und könnte zum Beispiel auch `tmp` sein. Also anstatt den Wert eines Objektes zu modifizieren kommt ein neues Element an der Stelle Index `1` in die Liste. Viele Grüße Mike
Gruss
Patrick _______________________________________________ python-de Mailingliste -- python-de@python.org Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an python-de-leave@python.org https://mail.python.org/mailman3/lists/python-de.python.org/ Mitgliedsadresse: mmueller@python-academy.de
Peter J. Holzer wrote:
Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns
Habs mir nochmals in Ruhe angehört. Oki, es gibt in Python also keine Aliase. Aber warum eigentlich nicht? Wäre doch manchmal praktisch, man könnte sie ja explizit als solche definieren... Gruss Patrick
On 2024-08-09 20:18, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
Es gibt einen sehr guten Vortrag zu dem Thema: Ned Batchelder - Facts and Myths about Python names and values - PyCon 2015 https://www.youtube.com/watch?v=_AEJHKGk9ns
Habs mir nochmals in Ruhe angehört. Oki, es gibt in Python also keine Aliase.
Aber warum eigentlich nicht? Wäre doch manchmal praktisch, man könnte sie ja explizit als solche definieren...
Der Hauptgrund dürfte sein, dass Guido Wert auf eine einfache, elegante Sprache gelegt hat[1]. Und die klare Trennung in "Namen"[2] und Objekte, wobei erstere immer Referenzen auf letztere sind, erfüllt dieses Kriterium (und ich kenne das in dieser Klarheit auch von keiner anderen Sprache). Ich weiß auswendig nicht, ob es überhaupt PEPs zu dem Thema gegeben hat, aber wenn, dann waren sie offensichtlich nicht überzeugend (entweder weil das Feature an sich nicht als generell nützlich angesehen wurde[3] oder weil die Semantik unklar war oder die Implementation problematisch wäre). Rein interessehalber: Von welchen Sprachen kommst Du, dass Du Aliases als üblich empfindest? Ich habe (in ungefährer zeitlicher Reihenfolge) in BASIC, Pascal, diversen Assemblersprachen, Modula-2, C, sh, awk, COBOL, Fortran, Perl, Java, Python und Go programmiert, und davon kennt eigentlich nur Perl Aliases (und das auch nur in gewissen Konstruktioen (beispielsweise for-Schleifen), nicht als allgemeines Sprach-Feature). Das With-Statement in Pascal und Modula ist verwandt, aber man stellt keinen Namen bereit sondern nur einen impliziten Scope. hp [1] Er legt vermutlich immer noch Wert darauf, aber er ist nicht mehr BDFL und somit nicht mehr die letzte Instanz, die über Erweiterungen von Python entscheidet. [2] For lack of a better word. Obwohl das Konzept wichtig ist, scheint es in der Python-Community kein allgemein übliches Wort dafür zu geben. Vielleicht sollten wir "lvalue" von den C-Leuten klauen. [3] Man spart sich maximal eine Indirektionsebene.
Peter J. Holzer wrote:
Rein interessehalber: Von welchen Sprachen kommst Du, dass Du Aliases als üblich empfindest?
Nennenswert programmiert habe ich lediglich als Teenager auf ZX-81 und C-64. Da hatte die For-Schlaufe aber noch kein "in", sie fallen somit als Schuldige weg. In letzter Zeit habe ich intensiv R und inbesondere das Tidyverse benutzt, aber dort muss man eigentlich fast nie Schlaufen coden. Dort ist übrigens auch die Slice-Funktion nicht kaputt (SCNR). Vermutlich dachte ich unbewusst, wenn die for-Schlaufe so komfortabel gleich entpackt und ich mit verständlichen Variablennamen auf die Liste zugreifen kann, wird sie das Zeug ja wohl auch wieder packen. Vielleicht könnte man eine "pfor"-Schlaufe entwickeln, die genau das nach jedem Durchlauf automatisch tut. Der Begriff "Alias" verwirrt mich auch ein wenig. Wenn ich Aliasnamen benutze und mich als Klaus-Bärbel oder auch mal als Matrosentom ausgebe und mir jemand eine blutige Nase verpasst, dann zeigen beide Alias-Namen auf dieselbe Person, die eine blutige Nase hat. Passt nicht so ganz zum Informatik-Konzept. Gruss Patrick
On 2024-08-10 20:09, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Der Begriff "Alias" verwirrt mich auch ein wenig. Wenn ich Aliasnamen benutze und mich als Klaus-Bärbel oder auch mal als Matrosentom ausgebe und mir jemand eine blutige Nase verpasst, dann zeigen beide Alias-Namen auf dieselbe Person, die eine blutige Nase hat. Passt nicht so ganz zum Informatik-Konzept.
Aliasing in Programmiersprachen bedeutet einfach, dass zwei Namen (oder allgemeiner zwei Ausdrücke) das gleiche Ding bezeichnen, was auch immer dieses Ding sein mag. Dein Beispiel, in dem Du verschiedene Namen trägst, entspricht genau dem Konzept von Python: patrick_rudin = Person() klaus_bärbel = patrick_rudin matrosen_tom = patrick_rudin # Hier haben wir jetzt eine Person mit drei Namen, nicht drei Klones. matrosen_tom.kriegt_eine_auf_die_nase() assert patrick_rudin.nase.blutet () ;-) Das ist auch insofern gleich, als im richtigen Leben ein Name nicht das gleiche wie eine Person ist eine Person mehrere Namen haben kann, und ein Name nicht einen anderen Namen bezeichnen kann, sondern nur eine Person. Es gibt natürlich auch Unterschiede, z.B. kann in Python ein Name immer nur auf genau ein Objekt zeigen, während wir es im richtigen Leben gewohnt sind, dass Namen nicht eindeutig sind und mehrere Personen bezeichnen können. Aber dieses Aliasing war offensichtlich nicht das, was Du gemeint hast. Du meintest, dass das Ding, das da gealiast wird, der Ausdruck selbst ist. Nach b = t[1] sollte b = 10 exakt die gleichen Auswirkungen haben wie t[1] = 10 Das passiert z.B. in Perl implizit in einer Schleife: ------------------------------------------------------------------------ #!/usr/bin/perl use v5.30; use warnings; my @a = (1, 2, 3); for my $x (@a) { $x = 10; } say for @a; ------------------------------------------------------------------------ gibt 10 10 10 aus. In C++ kann man das explizit mit Referenzen machen: ------------------------------------------------------------------------ #include <iostream> // 1 int main() { // 3 int a = 3; // 4 int &b = a; // 5 b = 5; // 6 std::cout << a << "\n"; // 7 return 0; // 8 } // 9 ------------------------------------------------------------------------ Aber C++ unterscheidet sich von Python dadurch, dass Variablen ihre Werte tatsächlich enthalten (und nicht nur auf sie verweisen). Im Beispiel oben gibt es 4 Bytes am Stack, die der Compiler als "a" bezeichnet und die zunächst mit dem Wert 0x00000003 überschrieben werden (Zeile 4) und später mit dem Wert 0x00000005 (Zeile 6). b wiederum sind 8 Bytes, die mit der Adresse des ersten Bytes von a initialisiert werden (Zeile 5) und weil der Compiler weiß, dass es eine Referenz ist, wird bei der Zuweisung in Zeile 6 nicht b selbst (also die Adresse) geändert, sondern das, worauf b zeigt. In C müsste man das explizit machen: ------------------------------------------------------------------------ ... int *b = &a; *b = 5; ... ------------------------------------------------------------------------ Hier ist b also kein Alias von a, sondern der Ausdruck *b (& bestimmt die Adresse eines Objekts, * dereferenziert einen Pointer). Die meisten Programmiersprachen, die ich kenne, folgen diesem "Eine Variable ist ein Speicherbereich, der einen Wert enthält" Modell, zumindest für einfache Typen. In Java sind Variablen vom Objekt-Typ immer Referenzen. Wenn man von Java kommt, ist das Python-Modell daher recht logisch: Da es in Python nur Objekt-Typen gibt (im Gegensatz zu Java) verhalten sich alle Typen so wie die Objekt-Typen in Java. hp
Peter J. Holzer wrote:
Dein Beispiel, in dem Du verschiedene Namen trägst, entspricht genau dem Konzept von Python:
Danke für die Erkläung. Mein Missverständnis bezog sich wohl in erster Linie tatsächlich auf die praktisch Anwendung, wenn man mit For-Schlaufen Listen mutiert. In Pygame erzeugt man halt dauernd viele Objekte, die laufend ihre Position und/oder Geschwindigkeit ändern. Mit verschachtelten Listen wird das relativ schnell mühsam.
Das passiert z.B. in Perl implizit in einer Schleife:
------------------------------------------------------------------------ #!/usr/bin/perl use v5.30; use warnings;
my @a = (1, 2, 3);
for my $x (@a) { $x = 10; } say for @ ------------------------------------------------------------------------
gibt 10 10 10 aus.
Ja, das würde ich instinktiv erwarten. Ich würde auch bei zahl = 5 zahl += 1 if zahl > 6 else 6 nicht das erwarten, was rauskommt. Aber man lernt dazu :) Gruss Patrick
On 2024-08-11 15:26, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Ich würde auch bei
zahl = 5 zahl += 1 if zahl > 6 else 6
nicht das erwarten, was rauskommt. Aber man lernt dazu :)
Die Syntax des ternary operators in Python ist IMHO ein Graus. Ich weiß nicht, was sich Guido dabei gedacht hat. Allerdings fällt mir als alternative Interpretation nur (zahl += 1) if zahl > 6 else 6 also if zahl > 6: zahl += 1 else: 6 ein und das ergibt nicht wirklich viel Sinn ("6" allein in einer Zeile ist zwar syntaktisch zulässig, tut aber nichts.) zahl (+= 1 if zahl > 6 else 6) ist für mich nicht möglich, weil es gleichbedeutend mit if zahl > 6: zahl += 1 else: zahl 6 wäre und da fehlt ein Operator zwischen "zahl" und "6". hp
Peter J. Holzer wrote:
Die Syntax des ternary operators in Python ist IMHO ein Graus.
Gewohnheit ist alles. Als ich zum ersten Mal in einem Land mit russischer Verkehrssprache war, wunderte ich mich auch über die Ladenbeschriftung "Produkti". Aber unser Begriff "Lebensmittel" ist auch nicht so sonderlich genau. Aber in welchen Deiner genannten Sprachen programmierst Du noch aktiv? Ich stelle mir den dauernden Wechsel ziemlich verwirrlich vor. Bin mal auf die Python-Eigenheiten gespannt, wenn ich mich endlich an Klassen wage... Gruss Patrick
On 2024-08-11 21:18, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
Die Syntax des ternary operators in Python ist IMHO ein Graus.
Gewohnheit ist alles.
Nach zehn Jahren habe ich mich immer noch nicht daran gewöhnt.
Aber in welchen Deiner genannten Sprachen programmierst Du noch aktiv? Ich stelle mir den dauernden Wechsel ziemlich verwirrlich vor.
Hauptsächlich vergesse ich in Perl immer die Strichpunkte am Ende der Zeile ;-). Python ist mit Abstand meine Hauptsprache. Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir). Außerdem habe ich noch einiges an Perl-Code zu pflegen und etwas Go-Code. C verwende ich noch manchmal für Tests. Und Shell-Scripts schreibe ich natürlich auch für einfache Aufgaben. hp
Peter J. Holzer wrote:
Hauptsächlich vergesse ich in Perl immer die Strichpunkte am Ende der Zeile 😉.
Aus Basic-Zeiten bin ich noch "if a = 100 then..." gewöhnt. In R geht das nicht, da muss wie fast überall "filter a == 100" verwendet werden. Da die Zuweisung in R mit "a <- 100" erfolgt, haben meine Finger die letzten Jahre gelernt, immer gleich == zu tippen. Damit falle ich nun bei Python auf die Nase, weil ich schon mehrmals solche If-Statements geschrieben habe: if a >= 100: a == 0 Irgendwann merkt man dann, dass sowas bloss Luftblasen-Trues fabriziert. Muss mal schauen, ob ich Spyder irgendwie beibringen kann, derartiges anzumeckern... Gruss Patrick
Am 11.08.24 um 23:43 schrieb Peter J. Holzer:
On 2024-08-11 21:18, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
Die Syntax des ternary operators in Python ist IMHO ein Graus.
Gewohnheit ist alles.
Nach zehn Jahren habe ich mich immer noch nicht daran gewöhnt.
Aber in welchen Deiner genannten Sprachen programmierst Du noch aktiv? Ich stelle mir den dauernden Wechsel ziemlich verwirrlich vor.
Hauptsächlich vergesse ich in Perl immer die Strichpunkte am Ende der Zeile ;-).
Wenn ich abwechselnd C und Python programmiere, verwechsele ich manchmal if (etwas) mit if etwas :
Python ist mit Abstand meine Hauptsprache.
Meine auch.
Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir).
JavaScript (.js) kommt nur im Zusammenhang mit html vor.
Außerdem habe ich noch einiges an Perl-Code zu pflegen und etwas Go-Code.
Altsprachen wie Pascal oder Java habe ich in meinen Bereich "entsorgt".
C verwende ich noch manchmal für Tests.
C verwende ich noch öfter. Das nächste Programm nach ISO zu durchsuchen. ( 1 byte alleinstehend unsigned char >= 0x080 ) Python macht z.B. Probleme in os.walk bei ISO in Dateinamen. Bei der Zusammensetzung von diakritische Zeichen erwarte ich in Python Probleme.
Und Shell-Scripts schreibe ich natürlich auch für einfache Aufgaben.
Ich mische gerne Python und bash mit Hilfe von os.system -- <http://www.hermann-riemann.de>
On 2024-08-13 00:44, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 11.08.24 um 23:43 schrieb Peter J. Holzer:
Python ist mit Abstand meine Hauptsprache.
Meine auch.
Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir).
JavaScript (.js) kommt nur im Zusammenhang mit html vor.
Das ist das, was man heute meistens mit "Frontend" meint.
Altsprachen wie Pascal oder Java habe ich in meinen Bereich "entsorgt".
Python ist fast 5 Jahre älter als Java[1]. hp [1] Erste veröffentlichte Version (0.9) von Python: 1991-02 Erste veröffentlichte Version (1.0) von Java: 1996-01 Wenn man andere Meilensteine (Beginn der Entwicklung, Version 1.0) heranzieht, schrumpft der Abstand deutlich, aber Python war immer vor Java dran.
Am 13.08.24 um 19:47 schrieb Peter J. Holzer:
On 2024-08-13 00:44, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 11.08.24 um 23:43 schrieb Peter J. Holzer:
Python ist mit Abstand meine Hauptsprache.
Meine auch.
Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir).
JavaScript (.js) kommt nur im Zusammenhang mit html vor.
JavaScript (.js) kommt bei mir nur im Zusammenhang mit html vor. node.js habe ich nicht verwendet.
Das ist das, was man heute meistens mit "Frontend" meint.
"PythonScript" ist noch neu und Java hatte ich anfangs bei mir nur in applet ausprobiert. ( object hat damals bei mir nicht funktioniert. )
Altsprachen wie Pascal oder Java habe ich in meinen Bereich "entsorgt".
Python ist fast 5 Jahre älter als Java[1]. [1] Erste veröffentlichte Version (0.9) von Python: 1991-02 Erste veröffentlichte Version (1.0) von Java: 1996-01 Wenn man andere Meilensteine (Beginn der Entwicklung, Version 1.0) heranzieht, schrumpft der Abstand deutlich, aber Python war immer vor Java dran.
Es gibt noch den Gesichtspunkt der privaten Verfügbarkeit Pascal hatte ich 1986 auf dem Atari ST und wurde später durch C ersetzt. Python kam bei mir etwa ab 2009 zu Einsatz. Es ersetzte C weitgehend bei Textverarbeitung und Verwaltung. Von den Uralt Sprachen kommt vielleicht noch mal LISP zum Einsatz. Ich denke da an einen Python artigen Präprozessor, der u.a. einige Klammern durch Einrückung ersetzt, Kleinbuchstaben relevant macht Schlüsselwörter ersetzt ( z.B. if elif .. durch COND ) arithmetische Ausdrücke in polnische Notation (wie bei FORTH) umsetzt .. .. -- <http://www.hermann-riemann.de>
On 2024-08-14 02:38, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 13.08.24 um 19:47 schrieb Peter J. Holzer:
On 2024-08-13 00:44, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 11.08.24 um 23:43 schrieb Peter J. Holzer:
Python ist mit Abstand meine Hauptsprache.
Meine auch.
Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir).
JavaScript (.js) kommt nur im Zusammenhang mit html vor.
JavaScript (.js) kommt bei mir nur im Zusammenhang mit html vor. node.js habe ich nicht verwendet.
Das ist das, was man heute meistens mit "Frontend" meint.
"PythonScript" ist noch neu
Ich nehme an, Du meinst PyScript.
und Java hatte ich anfangs bei mir nur in applet ausprobiert.
Java und JavaScript haben nichts miteinander zu tun (außer, dass die Netscape-Leute meinten, es sei eine gute Idee, die eigene Spriptsprache ähnlich zu nennen wie die von Sun lizensierte compilierte Sprache). hp
Am 14.08.24 um 08:26 schrieb Peter J. Holzer:
On 2024-08-14 02:38, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 13.08.24 um 19:47 schrieb Peter J. Holzer:
On 2024-08-13 00:44, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 11.08.24 um 23:43 schrieb Peter J. Holzer:
Python ist mit Abstand meine Hauptsprache.
Meine auch.
Frontend-Entwicklung erfordert auch JavaScript bzw. TypeScript (die in meiner Aufzählung gefehlt haben - Sigmund hätte seine Freud mit mir).
JavaScript (.js) kommt nur im Zusammenhang mit html vor.
JavaScript (.js) kommt bei mir nur im Zusammenhang mit html vor. node.js habe ich nicht verwendet.
Das ist das, was man heute meistens mit "Frontend" meint.
"PythonScript" ist noch neu
Ich nehme an, Du meinst PyScript.
Ja, daher ".
und Java hatte ich anfangs bei mir nur in applet ausprobiert.
Java und JavaScript haben nichts miteinander zu tun (außer, dass die Netscape-Leute meinten, es sei eine gute Idee, die eigene Spriptsprache ähnlich zu nennen wie die von Sun lizensierte compilierte Sprache).
Und sie anfangs (oder 1997) nur in html Seiten funktionierten. Etliche meiner letzten Erfahrungen mit Java ( vor mehr als 10 Jahre ) waren für ich abschreckend. -- <http://www.hermann-riemann.de>
On 2024-08-14 08:25, Hermann Riemann <nospam.ng@hermann-riemann.de> wrote:
Am 14.08.24 um 08:26 schrieb Peter J. Holzer:
Java und JavaScript haben nichts miteinander zu tun (außer, dass die Netscape-Leute meinten, es sei eine gute Idee, die eigene Spriptsprache ähnlich zu nennen wie die von Sun lizensierte compilierte Sprache).
Und sie anfangs (oder 1997) nur in html Seiten funktionierten.
Kommt auf die Plattform an- Für Solaris und Windows gab von Anfang an die komplette Laufzeitumgebung. (Tatsächlich konnte meiner Erinnerung nach ursprünglich nur der HotJava Browser Applets ausführen und der war selbst in Java geschrieben, also musste man wohl Java-Programme standalone ausführen können). In Linux dürfte es tatsächlich so gewesen sein, dass es das Plugin für Netscape vor der allgemeinen Laufzeitumgebung gab. hp
Am 14.08.24 um 13:22 schrieb Peter J. Holzer:
Für Solaris und Windows gab von Anfang an die komplette Laufzeitumgebung. (Tatsächlich konnte meiner Erinnerung nach ursprünglich nur der HotJava Browser Applets ausführen und der war selbst in Java geschrieben, also musste man wohl Java-Programme standalone ausführen können).
Ich habe 1997 unter windows 95 Java im browser verwenden. Das von browser Unabhängige kam bei mir später unter Linux. ( Probleme mit makefile und grep ) -- <http://www.hermann-riemann.de>
Peter J. Holzer wrote:
Rein interessehalber: Von welchen Sprachen kommst Du, dass Du Aliases als üblich empfindest?
Eigentlich nicht Alias, aber mir ist inzwischen eingefallen, dass ich mich vor geraumer Zeit intensiv mit C beschäftigt habe. Dort kann man natürlich beliebige Zeiger auf eine Adresse richten und dann rummutieren. Genau das will man mit den immutable-Typen ja verhindern, mal abgesehen von Effizienzfragen. Ironie der Geschichte ist irgendwie, dass man zum wirklichen Verständnis vom Python (sprich: Wissen, was man da tut) genau soviel Hintergrundwissen benötigt wie bei C. Die ganzen Abstraktionsebenen machen es nicht einfacher... Gruss Patrick
On 2025-10-06 22:46, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
Rein interessehalber: Von welchen Sprachen kommst Du, dass Du Aliases als üblich empfindest?
Eigentlich nicht Alias, aber mir ist inzwischen eingefallen, dass ich mich vor geraumer Zeit intensiv mit C beschäftigt habe. Dort kann man natürlich beliebige Zeiger auf eine Adresse richten und dann rummutieren.
Über C hatten wir in diesem Thread bereits diskutiert.
Ironie der Geschichte ist irgendwie, dass man zum wirklichen Verständnis vom Python (sprich: Wissen, was man da tut) genau soviel Hintergrundwissen benötigt wie bei C. Die ganzen Abstraktionsebenen machen es nicht einfacher...
Python ist keine einfache Sprache. Es gibt zweifellos Aspekte der Sprache, die ich nicht verstehe oder nicht einmal kenne. Man kommt aber in Python sehr schnell zu dem Punkt, an dem man korrekte Programme schreiben kann. Dorthin kommen in C die meisten nie (die schreiben nur Programme, die zufällig meistens das tun, was sie erwarten). hjp
Am 06.10.25 um 23:37 schrieb Peter J. Holzer:
On 2025-10-06 22:46, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Peter J. Holzer wrote:
Rein interessehalber: Von welchen Sprachen kommst Du, dass Du Aliases als üblich empfindest?
Eigentlich nicht Alias, aber mir ist inzwischen eingefallen, dass ich mich vor geraumer Zeit intensiv mit C beschäftigt habe. Dort kann man natürlich beliebige Zeiger auf eine Adresse richten und dann rummutieren.
Wenn ich irgendwie die id (Adresse vom Deskriptor?) einer Variablen an C übergebe.. ?
Ironie der Geschichte ist irgendwie, dass man zum wirklichen Verständnis vom Python (sprich: Wissen, was man da tut) genau soviel Hintergrundwissen benötigt wie bei C. Die ganzen Abstraktionsebenen machen es nicht einfacher...
Python ist keine einfache Sprache.
Das kommt darauf an wie viel Python. Wenn man in Python3 nur das verwendet, was in Python2 ging, ist Python einfach. Ansonsten ändert sich Python ( und andere Sprachen ) schneller, als wie ich lernen kann.
Man kommt aber in Python sehr schnell zu dem Punkt, an dem man korrekte Programme schreiben kann. Dorthin kommen in C die meisten nie (die schreiben nur Programme, die zufällig meistens das tun, was sie erwarten).
print("Hello world") geht in vielen Sprachen einfach. Bei größeren Programmen kam ich ( meist nach etlicher Fehlerbehebung ) meist in jeder Sprache dahin, was ich vom Programm erwartete. Hindernisse sind Zeitaufwand, ( fehlende, geänderte, aufwendig zu findende ) Schnittstellen. In python wäre das z.B. der cgi-Modul, den ich durch Zugriffe auf environment ersetzen will. Vor Python war privat C meine meist verwendete Programmiersprache. Etliche C Programme habe ich in Python neu programmiert. das betrifft Programme die Text bearbeiten, da ist C meist umständlicher zu programmieren. In Spezialfällen, wie eine Datei die eine Mischung aus utf und 8-bit Sonderzeichen enthält, oder wenn ich mit diakritische Zeichen experimentiere, würde ich C vorziehen. Ansonsten erwäge ich manchmal den C Präprozessor für Python zu verwenden. Datei 1: def f1(x): if x>0: f2(x) else: print(x) return x Datei 2: def f2(x) if x>0: return x-1 elif x<0: return x+1 else : return f1(x) Derartige 2 Dateien haben mir mal bei import Probleme bereitet, die bei include nicht auftreten würden. Als Kommunikation Python andere Sprachen erwäge ich shared memory. -- <http://www.hermann-riemann.de> bzw.: <https://www.hermann-riemann.eu/de>
On 10/7/25 09:01, Hermann Riemann wrote:
Am 06.10.25 um 23:37 schrieb Peter J. Holzer:
On 2025-10-06 22:46, Patrick Rudin <taxi_bs@gmx.ch> wrote:
Eigentlich nicht Alias, aber mir ist inzwischen eingefallen, dass ich mich vor geraumer Zeit intensiv mit C beschäftigt habe. Dort kann man natürlich beliebige Zeiger auf eine Adresse richten und dann rummutieren.
Wenn ich irgendwie die id (Adresse vom Deskriptor?) einer Variablen an C übergebe.. ?
Quick and dirty: #include <stdio.h> int main() { int x; x = 3; int *xptr; xptr = &x; *xptr = 5; x = x + 1; printf ("Jetzt: %d \n", x); printf ("Selbe Adresse %d und %d \n", &x, xptr); return 0; } Da wird halt nichts hinter "Objekten" versteckt, sondern man kann direkt via Speicheradresse rumwursteln. Ist hier aber wirklich offtopic. Man kann sich darüber streiten, ob die Logik bei Python einfacher ist. Gruss Patrick
Peter J. Holzer wrote:
Man kommt aber in Python sehr schnell zu dem Punkt, an dem man korrekte Programme schreiben kann. Dorthin kommen in C die meisten nie (die schreiben nur Programme, die zufällig meistens das tun, was sie erwarten).
"This brings us to the main disadvantage of C. If it can be done, then it can be done in C, but not necessarily done well". Harry Fairhead, "Fundamental C: Getting Closer to the Machine". Grüsse Patrick
participants (4)
-
Hermann Riemann -
Mike Müller -
Patrick Rudin -
Peter J. Holzer