Nach C: Python oder C++

Ruediger schrieb:
> Moin,

Moin Moin,

> Überlege mit C++ weiter zu machen. Sie baut ja quasi auf C auf und
> bringt die Aspekte der Objektorientierten Programmierung mit rein. Auf
> die reduzierte Möglichkeit von Pointern und Hardwarenaher Programmierung
> kann ich auch verzichten, da man das ja bereits in C bekommt.

C++ ist eine Obermenge von C. Alles was Du in C machen kannst, kannst Du 
auch in C++ machen. C++ ist eine sehr große Sprache und bietet nicht nur 
OOP. Um C++ wirklich sinnvoll einsetzen zu können, braucht es viel Zeit. 
Man kann aber auch anfangen seine C Software mit einem C++ Compiler zu 
übersetzen und dann langsam die neuen features von C++ zu nutzen.

> Andererseits begeistert mich Python schon seit langem. Ebenfalls
> objektorientiert, stelle ich mir die Data Science und Neural Network
> Features dieser Sprache sehr nützlich aber auch spaßig vor.

Ich würde Dir daher zu Python raten.

> Oder auf lange sich gar alle drei Sprachen? (C, C++, Python)

Ich verwende beruflich C++ jeden Tag. Wenn Du C++ kannst Du auch C. 
Neben einer Sprache wie C oder C++ ist eine Skriptsprache immer sehr 
hilfreich. Python scheint sich da im E-Technik-Umfeld durchgesetzt zu 
haben (Alternativen wären z.B. Ruby oder JavaScript). Wenn Du die Zeit / 
Lust hast, dann guck Dir C++ nach dem Du Python gelernt hast.

Sprachen lernen ist ja auch kein Thema, das man endgültig abgeschlossen 
hat. Ich muss auch täglich immer wieder Sachen nachschlagen. Einfach mal 
ein Problem in einer Sprache lösen! :-)

schöne Grüße,

Torsten

Torsten R. schrieb:
> Man kann aber auch anfangen seine C Software mit einem C++ Compiler zu
> übersetzen und dann langsam die neuen features von C++ zu nutzen.

Kann man machen, C++ lernt man dadurch aber eher nicht. Besser, man 
vergisst alles, was man ueber C weiss und faengt von vorn an -- C++ ist 
konzeptuell eine voellig andere Sprache.

Ruediger schrieb:
> Welche Sprache macht nach C am meisten Sinn?

Ich nehme an du benutzt C fuer Programmierung von Microcontrollers.
Vertiefe dich mal in eine Programmiersprache fuer den PC, zB C#.
Dann kann man die programmierte controller mit PC reden lassen und das 
zB schoene grafiken machen. Das oeffnet eine ganz neue welt.

Patrick aus die Niederlaende

Thomas schrieb:
> Ruediger schrieb:
>> Ebenfalls
>> objektorientiert, stelle ich mir die Data Science und Neural Network
>> Features ...
>
> Wird hier jetzt bald Bullshit-Bingo gespielt?

Nö, sind einfach nur englische Begriffe, wie sie halt im Bereich 
Computer - äh Verzeihung, elektronische Rechenmaschinen - häufig 
vorkommen.

Patrick C. schrieb:
> Ruediger schrieb:
>> Welche Sprache macht nach C am meisten Sinn?
>
> Ich nehme an du benutzt C fuer Programmierung von Microcontrollers.
> Vertiefe dich mal in eine Programmiersprache fuer den PC, zB C#.
> Dann kann man die programmierte controller mit PC reden lassen und das
> zB schoene grafiken machen. Das oeffnet eine ganz neue welt.

Das (und zwar beides) geht auch mit C++.

Ruediger schrieb:
> Oder auf lange sich gar alle drei Sprachen? (C, C++, Python)
>
> Auf Java hab ich gar keine Lust, ebenfalls Sprachen wie Javascript oder
> völlige Nischensprachen interessieren mich eher weniger.
>
> Was würdet ihr empfehlen?
Bleib doch bei C und versuche Dich in SDL oder GTK+ reinzuarbeiten, 
damit bekommst Du dann die Klickibunti-Grafiken und Fenster von C++ 
ebenfalls hin.
Der Vorteil von C++ ist keiner, weil man dann auch gleich auf Java 
springen kann.
Python weiß ich leider nicht.

Wenn dann macht Java von den genannten Sprachen noch Sinn, denn Java ist 
als einzige Sprache systemunabhängig - kommt darauf an was Du erreichen 
willst?

Torsten R. schrieb:
> Ich verwende beruflich C++ jeden Tag. Wenn Du C++ kannst Du auch C.
eine krasse Fehlaussage - ein guter C++ Programmierer ist kein guter C 
Programmierer und das gilt auch umgekehrt!
Du glaubst nur C zu beherrschen, weil Du es irgendwann früher mal gehabt 
hast - das ist wahrscheinlich? lange her und wenn Du beruflich sowieso 
nur noch C++ machst, kannst Du es eben nicht mehr ... und die 
erweiterten Möglichkeiten dank GTK+ und SDL sagen Dir wahrscheinlich 
sowieso nichts.

Ich würde mit Python beginnen und dort die Konzepte der 
objektorientierten Programmierung kennen zu lernen. Dies erweitert auch 
die C++ Kenntnisse. Python ist auf Plattformen wie Raspberry Pi sehr 
gebräuchlich.

Robert K. schrieb:
> Bleib doch bei C und versuche Dich in SDL oder GTK+ reinzuarbeiten,
> damit bekommst Du dann die Klickibunti-Grafiken und Fenster von C++
> ebenfalls hin.

Das ist im Falle von GTK+ ein Fall von "poor man's oo" und... echt 
jetzt?

> Der Vorteil von C++ ist keiner, weil man dann auch gleich auf Java
> springen kann.

C++ ist heute ähnlich plattformunabhängig wie Java, aber deutlich 
schneller und ressourcenschonender, und man kann nativ auch C-Libraries 
nutzen, ohne über das lahme JNI zu gehen -- und man muß sich nicht mit 
dem dummen Garbage Collector herumprügeln...

> Python weiß ich leider nicht.

Ist halt nochmal technisch eine ganz andere Nummer, und hat eine 
unglaublich große und leistungsfähige Infrastruktur.

> Wenn dann macht Java von den genannten Sprachen noch Sinn, denn Java ist
> als einzige Sprache systemunabhängig - kommt darauf an was Du erreichen
> willst?

Angesichts der unklaren Lizenzsituation ist das ein sehr unsicherer 
Kandidat für die Zukunftssicherheit. Und nach den jüngsten Änderungen in 
Java ist es heute sogar so, daß etliche Programme ihre eigene 
Java-Umgebung mitdeployen... Wow.

Experte schrieb:
> Naja, C++, Java, C# und mit Vorbehalt C: Kennst Du eine davon, kennst Du
> alle vier.
>
> Vergeudete Lebenszeit. Die Gruppe dieser drei oder vier Sprachen ist
> alles das gleiche, nur anders verpackt.

Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar 
Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist 
aufwändig, fehleranfällig und häßlich.

db8fs schrieb:
> Sheeva P. schrieb:
>> Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar
>> Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist
>> aufwändig, fehleranfällig und häßlich.
>
> Warum ist das häßlich?

Schon wegen der Namensräume. Schau Dir Deinen Code an: jede Funktion hat 
dafür extra ein eigenes Präfix. Und, bitte entschuldige... void-Pointer 
zu übergeben ist doch recht fehleranfällig und wenig typsicher, oder 
siehst Du das anders?

> Solange man höchstens 1 Objekt braucht isses doch erträglich.

Naja, Dein Beispiel ist ein Beispiel, nicht mehr, aber... also ich habe 
hier im Haus durchaus mehrere Sensoren, mehrere Lichtquellen, ... und da 
sind wir dann schon bei mehreren Objekten.

> Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das
> ganze Ableitungsgeraffel. Für viele ganz einfache Anwendungen auf
> Microcontrollerbasis doch vollkommen ausreichend. Mit FunctionPointern
> kann man auch Observer bauen und DI/IoC realisieren. Mehr Schreiberei
> mags vielleicht sein, aber nur schlecht ist das nicht, schließlich
> verstecken/überdeckt so manche andere Sprache auch gerne mal implizit
> vom Compiler übernommene Sachen.

Klar, man kann. Aber muß man, obwohl doch eine einfache Möglichkeit 
zur Verfügung steht, das Ganze wesentlich eleganter, ausdrucksstärker, 
und auch wiederverwendbarer zu gestalten? Warum?

Okay, ich weiß: dieses "Vererbungsgeraffel" ist für viele gestandene 
C-Leute ein echtes Hindernis und ein Grund für eine tief, sehr tief 
sitzende Abneigung. Aber wenn man das einmal verstanden hat, und so 
kompliziert ist es gar nicht (es wird nur oft sehr schlecht und 
kompliziert erklärt), kann das extrem nützlich sein -- und zwar, ja, 
auch bei einfachen Mikrocontrolleranwendungen.

Es ist halt einfach wesentlich schöner und lesbarer, etwas zu schreiben 
wie:

1

#include "hal.hpp"

2

3

int main(void) {

4

    Motor       motor       (PINDEF(B, PB1));

5

    Beleuchtung beleuchtung (PINDEF(B, PB2));

6

7

    Startknopf  startknopf  (PINDEF(D, PD1));

8

    Bremse      bremse      (PINDEF(D, PD2));

9

10

    Getriebe    gang        (PINDEF(D, PD3));

11

12

13

    while(1) {

14

        if (startknopf.gedrueckt()) { 

15

            beleuchtung.ein();

16

            if (gang.eingelegt() and bremse.gedrueckt()) {

17

                motor.ein();

18

            }

19

        } else { 

20

            motor.aus();

21

            beleuchtung.aus();

22

        }

23

    }

24

}

als

1

#include <avr/io.h>

2

3

/* outputs */

4

#define MOTOR       PB1

5

#define BELEUCHTUNG PB2

6

7

/* inputs */

8

#define STARTKNOPF  PD1

9

#define BREMSE      PD2

10

#define GANG        PD3

11

12

int main(void) {

13

14

    DDRB |= ((1 << MOTOR) | (1 << BELEUCHTUNG));

15

16

    while(1) {

17

        if(PIND & (1 << STARTKNOPF)) { /* startknopf.gedrueckt */

18

            PORTB |= (1 << BELEUCHTUNG); /* beleuchtung.ein */

19

            /* gang.eingelegt + bremse.gedrueckt */

20

            if( (PIND & (1 << PD3)) && (PIND & (1 << PD2)) ) { 

21

                PORTB |= (1 << MOTOR); /* motor.ein */

22

            }

23

        } else {

24

            PORTB &= ~(1 << MOTOR); /* motor.aus */

25

            PORTB &= ~(1 << BELEUCHTUNG); /* beleuchtung.aus */

26

        }

27

    }

28

}

Also, klar, ich kann da nur für mich sprechen, aber beim ersten Code 
sehe ich ohne Kommentare, was er tut. Klar, beim C-Code könnte man das 
auch noch nett in Funktionen verpacken und dann vielleicht ähnlich 
lesbar sein, aber... da würden diese Funktionen halt meistens nicht 
wiederverwendbar sein. Und am Ende habe ich für den ersten Code nichtmal 
Templates oder Vererbung benutzt, und die Kompilate sind -- waren: das 
habe ich 2017 gemacht -- tatsächlich sogar identisch!

Schau, ich bestreite keinesfalls, daß man alles, was in C++ geht, auch 
in C und auch in Assembler machen kann, wenn man es kann. Das ist nicht 
der Punkt. Für mich als jemand, der jeden Tag Code liest, analysiert, 
schreibt, ist es aber ein wesentliches Merkmal einer Programmiersprache, 
wie lesbar der Code ist -- oder, wie lesbar ich ihn bei gleichzeitiger 
Wiederverwendbarkeit gestalten kann.

Aus solchen Erwägungen heraus bin ich vor 10+ Jahren von meiner 
damaligen Lieblingsskriptsprache Perl zu meiner neuen, Python, 
gewechselt. Und ja, ich konnte sauberen und lesbaren objektorientierten 
Code in Perl schreiben, aber dafür mußte ich mir Mühe geben und 
diszipliniert sein. Heute in Python muß ich mir Mühe geben, um schlecht 
lesbaren Code zu schreiben. Und das macht für mich einen sehr, sehr 
wesentlichen und wichtigen Unterschied aus. (Mal von anderen Erwägungen 
wie Infrastruktur etc ganz abgesehen...)

> Verglichen mit Python isses freilich kompliziert, aber ist halt C und
> kein Python.

Ist halt ne andere Sprachfamilie und insofern nach meinem Dafürhalten 
gar nicht direkt vergleichbar, kein Problem insoweit. ;-)

db8fs schrieb:
> Sheeva P. schrieb:
>> Das ist, schlicht und ergreifend, Unfug. Man kann mit C zwar
>> Objektorientierung innerhalb gewisser Grenzen nachbilden, aber das ist
>> aufwändig, fehleranfällig und häßlich.
>
> Warum ist das häßlich? Solange man höchstens 1 Objekt braucht isses doch
> erträglich.

Dann würde ich aber nicht von objektorientierter Programmierung 
sprechen.

> Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das
> ganze Ableitungsgeraffel.

Aber gerade das ist eigentlich der Kern der Objektorientierung.
Also klar kann man in C auch ganz gut objektorientiert programmieren, 
solange man alles weglässt, was objektorientierte Programmierung 
ausmacht.

Wenn du C++ beruflich erst mal nicht benötigst, würde ich zunächst zu 
Python tendieren. Alleine schon um gewisse lästige Dinge automatisieren 
zu können.

python is besser. da gibtsgarbage collector ^^

db8fs schrieb:
> Was macht Polymorphie?

Es bietet mir die Möglichkeit, eine Funktion aufzurufen, und es wird 
dann automatisch zur Laufzeit die zum Objekt passende Implementation 
gewählt (dynamic dispatch). Der Rest ist syntaktischer Zucker, 
insbesondere:

> Implizit alle Eigenschaften übertragen, die der Abgelittene nach Liskov
> auch zwingend beibehalten müsste. Was macht der Compiler? Überträgt die
> Basisobjekt quasi als 'Feld' in das abgeleitete Objekt - implizit. Da kann
> ich die Basisklasse mir auch als Member halten, ohne abzuleiten.

Und dann behandle ich alle abgeleiteten Klassen in einem switch/case? 
Das ist zwar explizit, dafür aber unflexibel und erzeugt unnötige 
Abhängigkeiten.

db8fs schrieb:
> Sheeva P. schrieb:
>> db8fs schrieb:
>>> Sheeva P. schrieb:
> Stimmt. Hängt halt vom Design des jeweiligen Controller-Objektes (z.B.
> Haus) ab, was alles rübergegeben wird. Ich sag ja nicht, dass C eine
> Programmiersprache ist, die Objektorientierung explizit durch vom
> Sprachdesign her unterstützt. Aber wählt man die anzulegenden Objekte
> richtig, kann man es zumindest gut in die Richtung annähern. OO-Design
> kann man also auch mit C machen.

Klar kann man das tun. Aber wie Du schon absolut richtig sagst: C 
unterstützt das nun einmal nicht nativ, und man muß alles selbst machen, 
während C++ dafür aus dem Stand eine hervorragende Unterstützung bietet. 
Warum sollte ich etwas selbst machen, das es woanders schon fertig gibt 
und das nichts kostet? Sogar der (ohnehin einmalige) Aufwand, OO zu 
lernen, wird bei C++ viel kleiner sein. ;-)

Nebenbei bemerkt ist die OO ja nicht zuletzt auch aus dem entstanden, 
was bei prozeduralen ohnehin schon guter Stil war. Sehr schön kann man 
das in dem Buch "Making Embedded Systems" von Elecia White lesen 
(O'Reilly).

> Weil ich glaube, dass die Eleganz bei der Entwicklung im SW-Design und
> nicht in der Wahl der Programmiersprache liegen sollte.

Naja, ich glaube, daß die Eleganz einer Software nicht nur in ihrem 
Design, sondern auch in ihrer Implementierung liegt. In beiden Fällen 
erscheint mir C++ aber dann schon deswegen im Vorteil, wenn es mehr 
Paradigmen unterstützt und somit eine größere Auswahl hinsichtlich der 
verfügbaren Designs bietet.

> Klar, man kann
> in Python schön einen Draft machen und einen Wrapper um C-Funktionen
> bauen. Wie sollte man denn den Wrapper machen? Für volle Multiplizität
> auslegen, oder sähe es nicht eleganter aus, wenn man nur ein Objekt im
> Python bräuchte, dass nur ein Singleton-C-'Objekt' bedienen müsste?
> Gerade bei Low-Level-Libraries fände ich das ein schöneres API-Design
> als irgendwelche HANDLEs über Programmiersprachengrenzen hinaus
> teilen/wrappen zu müssen.

Jaaaa... und nein. Python ist (meistens) eine interpretierte 
Skriptsprache und somit eine gänzlich andere Sprachfamilie. Von den 
technischen Unterschieden, die hier sicherlich jedem bekannt sind, 
einmal abgesehen, ist das letztlich nur eine ökonomische Frage, ob man 
C++ oder Python verwendet. Trotzdem kann es sinnvoll sein, Teile einer 
Software in schnellem und ressourcensparendem C oder C++ zu entwickeln, 
und diese Teile dann in eine interpretierte Skriptsprache wie Python 
einzubetten. Dazu habe ich sogar ein sehr konkretes Beispiel aus meiner 
eigenen jüngeren praktischen Vergangenheit.

In den letzten Wochen habe ich ein bisschen mit Natural Language 
Processing und Machine Learning experimentiert mit dem Ziel, Trolle und 
andere Störer in einer Echtzeit-Kommunikation (think IRC, Webchat, 
Messenger, ...) automatisiert zu erkennen. Python bietet mit dem NLTK, 
scikit-learn und andere eine herausragende Infrastruktur für so etwas. 
Andererseits geht es um Echtzeitkommunikation, das muß also gewisse 
zeitliche Beschränkungen einhalten, und schon die Aufbereitung der Texte 
(Tokenizing, Lemmatisierung / Stemming, Umformung in eine Bag Of Words, 
Erzeugung von N-Grammen, ...) ist ziemlich aufwändig, sowohl im Hinblick 
auf den Ressourcen-, als auch den Zeitbedarf.

Also habe ich diesen Teil in einer kleinen C++-Klasse implementiert und 
sie mit Boost::Python in mein Python-Programm eingebaut. Trotzdem kann 
ich sie zusammen mit der erwähnten Python-Infrastruktur zur Lösung des 
Problems nutzen, das geht ganz wunderbar und zudem extrem performant. 
Auf diese Weise bekomme ich das Beste aus beiden Welten: die extreme 
Flexibilität und Infrastruktur von Python und die extrem hohe 
Performance von C++.

>> Okay, ich weiß: dieses "Vererbungsgeraffel" ist für viele gestandene
>> C-Leute ein echtes Hindernis und ein Grund für eine tief, sehr tief
>> sitzende Abneigung. Aber wenn man das einmal verstanden hat, und so
>> kompliziert ist es gar nicht (es wird nur oft sehr schlecht und
>> kompliziert erklärt), kann das extrem nützlich sein -- und zwar, ja,
>> auch bei einfachen Mikrocontrolleranwendungen.
>
> Ey, ich bin C++'ler,

Okay, dann gilt das nicht für Dich, aber in anderen Fällen sieht das 
leider ein bisschen anders aus, fürchte ich. ;-)

> aber bei reinen C-Projekten, die eher
> strukturiert/prozedural orientiert angelegt sind, wünscht man sich
> tatsächlich manchmal eine bessere Zuordenbarkeit, welches Modul jetzt
> für was zuständig ist.

Bitte verzeih', aber inwieweit hat das Deiner Meinung nach mit dem 
jeweiligen Paradigma oder der verwendeten Sprache zu tun?

> Da glaub ich, dass der obige Ansatz bissl in die
> Richtung geht, sagen zu können, unter dem Modul 'Haus' gruppiere ich
> alles, was funktional dazugehört.

Naja, ich würde das halt... objektorientiert machen. Ich habe dann also 
ein Haus, und dieses Haus hat beliebig viele Sensoren und Aktoren.

> Ändere ich was am 'Haus' bzw. möchte
> was davon wissen, greif ich genau auf das Objekt zu. Und leg mir nicht
> ne potentielle Objekt-Reihenhaussiedlung an, wovon dann nur ein einziges
> genutzt wird. Wirds dann mal mehr als ein Haus, benennt man den
> Controller 'Haus' halt zu 'Haeuser' um und modifiziert nach Gusto. Mit
> Code arbeiten muss man als Programmierer so oder so, ob man will oder
> nicht.

Bitte versteh' mich nicht falsch, ich möchte hier keinem Overengineering 
das Wort reden, aber: mein Haus-Objekt als eigenständige Einheit kann am 
Ende in vielen verschiedenen Inkarnationen auftreten, obwohl es immer 
dasselbe Haus ist. Mein Haus kann also ein einfaches Einfamilienhaus, 
ein Bestandteil zweier getrennter Doppelhaushälften, oder auch ein 
Bestandteil einer Reihenhaussiedlung sein. Und egal, was ich damit 
verwalten oder steuern will: es ist immer dasselbe Haus, das ich nur ein 
einziges Mal schreiben muß. Ich bin ein Anhänger von Larry Walls vier 
Kardinaltugenden des Programmierers, besonders der Faulheit. ;-)

>> Es ist halt einfach wesentlich schöner und lesbarer, etwas zu schreiben
>> [...]
>
> Findeste?

Ja, unbedingt!

> Aus deiner Modellierung käme für mich z.B. überhaupt nicht der
> strukturelle Zusammenhang zwischen Motor, Beleuchtung, Startknopf,
> Bremse und Gang hervor. Wenn man das in C abbilden wollte, müsste man
> structs zusammmensetzen, z.B. sturct Fahrzeug oder so. Wie gesagt, mein
> obiger Ansatz ist was Controllerobjekte, nicht für Daten.

Was hinderte mich denn, das in C++ genauso zu machen, und Motor, 
Beleuchtung, Startknopf, Bremse und Gang in eine Klasse "Fahrzeug" zu 
packen und die kleine Logik aus der main()-Funktion in eine Methode 
dieser Klasse? Genau, nichts, das muß ich Dir doch nicht erklären. Und 
trotzdem bleibt es ebenso offensichtlich, was der Code tut.

>> die Kompilate sind -- waren: das
>> habe ich 2017 gemacht -- tatsächlich sogar identisch!
>
> Jo, gut.

Deine etwas... knappe Antwort darauf finde ich, Pardon, jetzt schon ein 
wenig unbefriedigend, denn das ist in den meisten Diskussionen zum Thema 
OOP, die ich hier im Forum verfolgen durfte, einer der wichtigsten 
Hauptpunkte: daß OOP so schrecklich groß und aufgebläht und teuer sei. 
Das ist aber gar nicht so, wenn man einige einfache Regeln einhält, und 
deswegen spricht in der Sache auch rein gar nichts gegen C++, sondern 
stattdessen vieles dafür.

> Klar, Wahl der richtigen Mittel. Oft ist bei bestehenden Projekten diese
> Wahl bereits getroffen - was willsten machen? Alles auf der neu
> schreiben? Hast halt die einen Fehler dann nicht mehr und dafür dann
> andere.

Das kann natürlich nicht die Idee sein, und das habe ich auch nicht 
behauptet. Allerdings ist die Abwärtskompatibilität mit C eine der 
wichtigsten Stärken von C++ (allerdings hie und da auch eine der größten 
Schwächen ;-)). Insofern kann ich -- und habe ich schon häufig -- 
einfach vorhandenen C-Code in C++ genutzt, meistens funktioniert das 
wunderbar.

> Python ist vom Sprachkonzept her, sehr gut durchgedacht. Musst halt
> potentiell oft die Laufzeitumgebungen, Packages und Gedöns pflegen - den
> Overhead haste in C/C++ nicht so, wenn du nicht immer den neuesten Kram
> verwendest.

Für soetwas gibt es in Python das "virtualenv" und in neueren Versionen 
das Modul "venv". Damit erstelle ich mir eine in sich geschlossene 
Umgebung mit ihrem eigenen Interpreter und ihren eigenen Modulen, die 
ich wahlweise auf bestimmte Versionen festzurren und auch jederzeit 
aktualisieren kann, ganz unabhängig von der Systemumgebung und 
-Installation -- "pip install -U -r reqirements.txt" reicht dazu 
vollkommen aus, und schon ist alles aktuell. Dabei erstelle ich die 
betreffende Datei einfach mit "pip freeze > requirements.txt", und wenn 
ich die dabei verwendeten Modulversionen benutzen müchte, lasse ich beim 
ersten Befehl einfach den Schalter "-U" weg... einfacher geht's kaum. 
;-)

db8fs schrieb:
> Rolf M. schrieb:
>>> Polymorphie braucht mer bei nur einem Objekt nicht, spart man sich das
>>> ganze Ableitungsgeraffel.
>>
>> Aber gerade das ist eigentlich der Kern der Objektorientierung.
>
> Na ja, auch. Eigentlich wird ja immer empfohlen explizit vor implizit.

Äh, eigentlich kenne ich das nur aus dem Zen Of Python (PEP20)...

> Was macht Polymorphie? Implizit alle Eigenschaften übertragen,

Nein, explizit. Ich gebe ja bei meiner Klasse explizit an, wovon sie 
erbt, womit dann auch explizit klar ist, was sie erbt... ;-)

> die der
> Abgelittene nach Liskov auch zwingend beibehalten müsste.

Nicht die Eigenschaften, sondern die Schnittstelle.

> Was macht der
> Compiler? Überträgt die Basisobjekt quasi als 'Feld' in das abgeleitete
> Objekt - implizit. Da kann ich die Basisklasse mir auch als Member
> halten, ohne abzuleiten.

... was ohnehin viel öfter eine gute Idee ist, als manche 
Vererbungsfanatiker wahrhaben wollen. ;-)