Aller Anfang ist schwer

[BlackJack]

@Leonidas: Bezüglich der Übergabe würde ich Dir bei der Wortwahl widersprechen. Es werden eben doch die Objekte selbst übergeben, und zwar immer. Die andere Alternative wäre, dass nicht das Objekt selbst übergeben wird, sondern eine Kopie. Und das passiert ja gerade nicht. Der Code innerhalb einer Funktion/Methode greift auf das selbe Objekt zu wie der Code ausserhalb, der es übergeben hat.

Ich denke Tom_H spricht da ein Problem an was nicht Anfänger betrifft, sondern Leute die Sprachen kennen, bei denen es verschiedene Übergabemöglichkeiten gibt, und die sich jetzt fragen wann Python nun was macht, weil man es nirgends angeben kann/muss.

Anfänger kennen diese Unterscheidung nicht, und da reicht es zu sagen, dass die Objekte an verschiedene Namen gebunden werden können, es dabei aber immer das selbe Objekt bleibt. Das sollte auch nicht so schwer zu vermitteln sein.

@snafu: Ich denke was cofi meinte war eher das man es so behandeln sollte als wäre es ein Implementierungsdetail, denn es zu benutzen führt zu schwerer verständlichem Quelltext. Man sollte möglichst immer `int()` und `bool()` hinschreiben wenn man umwandeln möchte, auch wenn das nicht nötig ist, und man sollte es ausser bei Code-Golf nicht verwenden um ``if``\s zu ersetzen. Also man sollte die Schweinereien unterlassen, die bei Forth oder BASIC als guter Stil oder clever gelten.

[Tom_H]

...Na, und dann empfiehlst du C, das als ANSI C erstens gar keine Booleans hat und als C99 diese quasi als aliase für 0 und 1 definiert sind. Interessant, aber nicht sehr konsequent von dir

Eigentlich hätte ich ja Pascal/Modula sagen wollen - das habe ich mir aufgrund der geringen Verbreitung verkniffen. Damit meine ich übrigens Wirth-Pascal und nicht diesen "zusammengerührten Topf", den B||L&& auf die Kunden losgelassen hat.
C hat den Vorteil, daß man das auf jeder Plattform (vom 50-Cent MuC/PIC bis zum Mainframe) einsetzen kann und wirklich für jeden denkbaren Fall Libraries und APIs vorhanden sind. Wenn man eine universell benutzbare Sprache lernen will, dann kommt man an C nicht vorbei. Ich mag diese Sprache garnicht und ich finde die Syntax furchtbar - aber das sind persönliche Befindlichkeiten.

Wie jemand schon sagte, die Regel ist einfach: "IMMER" Es werden immer Referenzen übergeben, nie die Objekte selbst. Und Referenzen sind keine Pointer.

Danke für den Denkanstoß - so langsam wird mir der Mechanismus klar.
Ich muß mich hier von "alten Mustern" lösen. Es sind nunmal keine klassischen Stack-Maschinen mehr - in den letzten Jahrzehnten ist doch mehr als nur eine zusätzliche Abstraktionsschicht dazugekommen.
Damit ist aber immutability eine reine Konvention und keine Notwendigkeit - richtig?

mfg, Tom

[Leonidas]

@BlackJack: Ja, gut, Wikipedia nennt das Call by Object. Aber Ich denke, wir haben die ellenlange Diskussion beide miterlebt, müssen wir nicht nochmal aufrollen

Eigentlich hätte ich ja Pascal/Modula sagen wollen - das habe ich mir aufgrund der geringen Verbreitung verkniffen. Damit meine ich übrigens Wirth-Pascal und nicht diesen "zusammengerührten Topf", den B||L&& auf die Kunden losgelassen hat.

Also ich kenne nur das Turbo Pascal 7.0 (selbst damals wars schon heftig obsolet und die Hardware war schnell genug um den Division By Zero-Fehler zu triggern) und tatsächlich war das meine erste Programmiersprache. Ich denke aber nicht, dass sie so besonders Einsteigerfreundlich war, um ehrlich zu sein. Ich habe zwar Blöcke verstanden, aber irgendwie hat mir 'End' vs. 'End.' damals total die Probleme gemacht. Wieder so ne Sache, die man in Python nicht hat. Und wirklich gut fand ich das deklarieren der Typen nicht, das hat für mich nicht so wahnsinnig viel Sinn gemacht und sicherlich zu mehr Frustrationen geführt als es beim Debuggen geholfen hat (ergo gar nicht, denn Einsteigerprogramme sind meist nicht so komplex dass man so wahnsinnige Probleme bei der Parameterübergabe hat). Was hingegen gut war, war die IDE direkt mit Highlighting, und dann konnte das Programm blitzschnell kompiliert werden und ausgeführt werden. Mit dem ``crt``-Modul konnte man als Programmieranfänger bunten Krimskrams auf den Bildschirm zaubern. Das war schon ne feine Sache. Insofern ist Processing.js oder vielleicht noch Processing das was dem heutzutage am nähesten kommt.

C hat den Vorteil, daß man das auf jeder Plattform (vom 50-Cent MuC/PIC bis zum Mainframe) einsetzen kann und wirklich für jeden denkbaren Fall Libraries und APIs vorhanden sind. Wenn man eine universell benutzbare Sprache lernen will, dann kommt man an C nicht vorbei. Ich mag diese Sprache garnicht und ich finde die Syntax furchtbar - aber das sind persönliche Befindlichkeiten.

Gut, das stimmt zwar, dennoch sprechen wir von Anfängern. Und die fangen in der Regel (von Arduino ausgenommen, aber das nutzt auch kein C sondern Wiring) nicht an Microcontroller zu programmieren. Sondern auf ihrem PC, mit Tastatur und sofortigem Feedback. Eventuell sogar schon in ihrem Browser (siehe Processing.js). Andererseits finde ich den Einwand zu C-Libraries nicht mehr so relevant, das war vielleicht noch 2003 ein gültiger Einwand, aber heutzutage immer weniger. Zum einen kann man C-Libraries mittels ctypes ziemlich brauchbar einbinden, zum anderen hat PyPI momentan 17982 Packages. Da sind die meisten Sachen brauchbar abgedeckt und ich würde sagen, sogar besser als in C. Nehmen wir mal so Projekte wie TurboMail, SQLAlchemy, Celery, lxml, Pygments. Zu den meisten gibt es *irgendwelche* C-Äquivalents, aber nicht annähernd so gut. Gilt natürlich auch andersrum, aber ich wünsche mir in C schon öfters einfach irgendeine Python-Library rauspacken zu können um ein Problem zu lösen.

Ich muß mich hier von "alten Mustern" lösen. Es sind nunmal keine klassischen Stack-Maschinen mehr - in den letzten Jahrzehnten ist doch mehr als nur eine zusätzliche Abstraktionsschicht dazugekommen.
Damit ist aber immutability eine reine Konvention und keine Notwendigkeit - richtig?

Naja, wenn du Stack-Maschinen magst - Forth und seine jüngeren, klügeren Kinder Joy, Cat und Factor existieren Letztere sind sogar ziemlich interessant wenn man die Herausforderung annimmt. Und intern ist sowohl die JVM als auch die Python-VM als Stack-Maschine implementiert. Aber wie du sagtest, es gibt obendrauf natürlich eine Menge Abstraktionen. Und natürlich, Immutability ist eine Konvention, na, vielleicht mehr als das, denn Python erlaubt ohne Tricks nicht das modifizieren von immutablen Objekten. Aber klar, der RAM in dem das Objekt abgelegt ist, ist natürlich beschreibbar

[cofi]

@snafu: Genau das was BlackJack herausgelesen hat meinte ich.
Eben sowas:

Code: Alles auswählen

valid_count = 0
for x in xs:
    valid_count += predicate(x)

Da finde ich das hier weit klarer:

Code: Alles auswählen

valid_count = 0
for x in xs:
    if predicate(x):
        valid_count += 1

Oder sowas:

Code: Alles auswählen

[fun_a,fun_b][predicate(x)](x)

statt

Code: Alles auswählen

if predicate(x):
    fun_b(x)
else:
    fun_a(x)

Ich weiss nicht, ob man `issubclass(bool, int)` als bewusst gewaehltes Konzept behandeln will. Schliesslich stuetzt sich idiomatisches Python eher auf `truthy` bzw `falsy` Werte, die ich schon Ansprach. Worauf ich rauswollte und ich jetzt auch mit Beispielen garniert habe: Man sollte `True`/`False` als Wahrheitswerte und nicht als Zahlen benutzen or else ...

@BlackJack: Das ist doch auch in Python clever. Es gilt halt, dass "cleverer Code" synonym zu "schwer verstaendlicher Code" ist.

@Tom_H: Ja immutability ist reine Konvention fuer Exemplare von in Python erstellter Klassen. Bei C-Erweiterungen bin ich mir grad unsicher, kann das noch jemand abdecken?

[BlackJack]

@cofi: Bei Datentypen die in C implementiert sind, hast Du die Wahl ob Du denen ein `__dict__()` verpassen möchtest oder nicht. Wenn Du das nicht machst und den Zustand wirklich innerhalb des C-Teils kapselst, dann kommt man da von Python aus nicht heran und kann an dem Objekt nichts verändern was nicht über Methoden vorgesehen ist. Ausser natürlich mit ein wenig „cleverer“ `ctypes`-Magie.