complier / datentyp

[reinerdoll]

für die profis wohl aus dem ärmel, für mich endlos suchen ... also 2 fragen :

a) a= input("wert : ")
a = a/2

.. klar, läuft nicht weil a beim input als string behandelt wird. ich weiß auch wie ich es löse, aber ich möchte wissen, warum python die typkonversion bei der zweiten zeile nicht selbständig durchführt ?
vgl. visual basic :
a = inputbox("a")
b = a/2
msgbox(b)

b) python ist eine interpretersprache (z.b. keine var-deklaration) ?
wieso wird dann trotzdem (in _pycache_) ein compilerlauf abgelegt ??

[kbr]

Python ist eine stark typisierte Sprache, bei der keine impliziten Typ-Änderungen erfolgen. Und das ist gut so.
Weiter ist Python auch eine kompilierende Sprache. Der Quelltext wird zunächst in Bytecode kompiliert, dieser dann interpretiert.

[Sirius3]

Ein Auto hat vier Räder, warum hat dann ein Fahrrad nur zwei? Du gehst davon aus, dass wenn eine Programmiersprache etwas so behandelt, es für alle gelten muß?

Du bringst viel durcheinander. Python ist eine dynamische stark typisierte Programmiersprache; der Typ ist zwar nicht explizit angegeben, aber es wird auch nicht automatisch von einem in den anderen umgewandelt.

Und dass der Compilierungsschritt nicht getrennt von der Programmausführung stattfinden, heißt nicht, dass es ihn nicht gibt. Um aber nicht jedes mal wieder alles Compilieren zu müssen, wird das Ergebnis dieses Schritts gespeichert.

Ob es Variablendeklaration gibt oder nicht, ist von den oben genannten Punkten wiederum ein völlig unabhängiges Thema.

[reinerdoll]

a) daß es so ist, hab ich schon verstanden, was mich interessiert ist die frage des "warum".
welchen vorteil (.."und das ist gut so" steht in einer antwort) bringt die feste typisierung z.b. des input-werts ?
(ich sehe es in vb so als vorteil, und verstehe den vorteil in python nicht )

b) in wiki z.b. wird python als interpretersprache beschrieben. stimmt ja offenbar nicht (im ursprünglichen sinn eines interpreters) sondern es wird auf einen zwischencode compiliert, der dann
in einer art vm interpretiert wird. also eigentlich eine compilersprache, oder ? oder beides ?

[__deets__]

Zu a): Implizite Typkonvertierungen koennen bequem sein, produzieren andererseits aber auch subtile Fehler. So koennen zB Benutzereingaben fehlerhaft sein, und das Programm macht trotzdem weiter. Statt durch einen Fehler abzubrechen, welcher entweder Fehleingaben (etwas unbequem) verhindert, oder eben den Programmierer zur sinnvollen Behandlung zu zwingen. Wo genau man da schneidet ist durchaus Geschmackssache. Python hat das "explicit is better than implicit"-Mantra, und das ist dann eben eine der Stellen, wo man das so entschieden hat.

Und zu b): die Diskussion zeigt die Grenzen einer solchen simplen Kategorisierung auf. Java oder C# werden zwar offiziell kompiliert, doch ihr Byte-Code dann interpretiert. Was also sind das jetzt? Compiler- oder Interpretersprachen? Und wenn ich zur Laufzeit Code generieren kann (und sowas geht gerade bei Java zB), was ist *das* dann wiederum? Und wenn man den PyPy-Interpreter benutzt, der nach Moeglichkeit Python zu Maschinensprache uebersetzt???? Du siehst schon, das alles auseinander zu droeseln ist ein bisschen muessig. Weshalb man es IMHO laesst.

Die PYC-Files haben Vorteile - leicht schnellerer Interpreter-Start, schwieriger zu reverse engineeren beim Kunden - und Nachteile weil sie "irgendwo" entstehen und gelegentlich aufgegriffen werden, obwohl man das eigentlich nicht will. Ich persoenlich wuerde mir wuenschen, man haette auch hier "explicit is better than implicit" gewaehlt, und diese Erzeugung nur durch explizite Aufforderung gemacht. Ist leider anders gekommen.

[/me]

welchen vorteil (.."und das ist gut so" steht in einer antwort) bringt die feste typisierung z.b. des input-werts ?
(ich sehe es in vb so als vorteil, und verstehe den vorteil in python nicht )

Möge die Theorie jemand anders liefern, hier ein primitives praktisches Beispiel. Ich möchte zehnmal ein Dollarzeichen.

Code: Alles auswählen

>>> "$" * 10
'$$$$$$$$$$'

Prima funktioniert. Jetzt möchte ich zehnmal eine 1.

Code: Alles auswählen

>>> "1" * 10
'1111111111'

MIt automatischer Typumwandlung aufgrund des Stringinhalts hättest du da eine unerwünschte 10.

[__deets__]

Schoenes Beispiel

Wobei man auch Anmerken kann, dass die Ueberladung von + und * bei Strings eigentlich ein Fehler ist. VB benutzt (glaube ich) . zur Konkatenation, und ob es so ein vervielfachen gibt, weiss ich nicht.

[reinerdoll]

vielen dank.
sehr gute aussagen, gut zu verstehen !

also ein compinterpreter sozusagen
klar, die theorie ist immer zu einfach gemessen an der praxis ...

contencate in vb : a = b&c, . ist php z.b. oder ? (egal..)

-----------

anschlußfrage an die python/compiler geschichte :

werden heute manchmal professionelle klassenbibliotheken als compiled python erstellt, oder ist das immer alles c ? man braucht ja für das compiled python immer die "vm"-installation.

[Sirius3]

@/me: das ist aber nur dann der Fall, wenn man die Multiplikation von Strings mit einer Zahl so definiert.
Es könnte genauso gut in einem ValueError enden, weil "$" nicht als Zahl interpretierbar ist. Also alles nur Interpretationssache.

[noisefloor]

Hallo,

@rainerdoll: wenn du Python (bzw. grundsätzlich irgendeine Programmiersprache), dann musst du dich schon auf deren Konzepte und Idiome einlassen. Wenn du latent alle Designentscheidungen der Entwickler hinterfragst, weil du unzufrieden damit bist bzw. das anders siehst, dann wird das mit dem Lernen nie was, weil du an dir selber scheiterst.

Gruß, noisefloor

[reinerdoll]

@noisefloor : hinterfragen heißt ja nicht kritisieren (stünde mir auch gar nicht zu..), sondern verstehen wollen. das schadet nicht hab ich gelernt ...
und hat ja nun auch funktioniert, soweit es die antworten angeht. also nochmal : danke !

[__deets__]

Professionelle Bibliotheken oder Programme kommen auch ohne C aus. Wobei man die wenn gewünscht durch cython jagen kann. Dann sind sie kompiliert im weitesten Sinne.

[DasIch]

Die .pyc Dateien sind wirklich nur ein Cache, wie auch der Name des Ordners __pycache__ schon sagen sollte. Python Bytecode ist auch relativ gut lesbar weil CPython keine nennenswerten Optimierungen ausführt, macht also reverse engineering nur bedingt schwieriger, der Cache ist in der Praxis dementsprechend auch nur von eingeschränktem Wert.

Darüberhinaus funktioniert eigentlich fast jede Sprache, bei der keine Binaries produziert werden, so dass Code geparst wird und in eine leichter zu interpretierende Form kompiliert wird. Das trifft sicherlich auch auf VB und PHP zu. Sprachen bei der die Kompilierung aufwendig ist (Java, C#) trennen den Compiler von der VM, macht aber keinen wesentlichen Unterschied. Manchmal gibt es sogar mehrere Compiler, z.B. wenn man einen JIT hat wie schon angesprochen bei PyPy oder sogar mehrere JITs wie bei JS inzwischen üblich.

werden heute manchmal professionelle klassenbibliotheken als compiled python erstellt, oder ist das immer alles c ? man braucht ja für das compiled python immer die "vm"-installation.

"compiled python" gibt es nicht. Die allermeisten Module die es gibt sind in Python geschrieben. Zu C (C++, Fortran, vielleicht auch Rust) greift man nur wenn es aus Performance gründen sinnvoll ist z.B. im Machine Learning Bereich.

[__blackjack__]

@reinerdoll: Bei der Frage nach der automagischen Typumwandlung gibt es für JavaScript IMHO genügend Beispiele wo man sich an den Kopf fassen kann. Ein Klassiker ist:

Code: Alles auswählen

> ('b' + 'a' + + 'a' + 'a').toLowerCase()
'banana'

Ergänzend zu DasIch's Aussage zu in C geschriebenen Python-Bibliotheken sind vielleicht noch Anbindungen an schon bestehende Bibliotheken zu erwähnen, also welche die beispielsweise in C geschrieben sind, aber nicht spezifisch für Python. Da kann man dann natürlich das `ctypes`-Modul aus der Standardbibliothek oder das externe `cffi` verwenden, aber oft gibt es auch eine in C oder Cython geschriebene Python-Anbindung an solche Bibliotheken. Beispielse sind GUI-Rahmenwerke (Gtk, Qt, …) oder Datenbank-Client-Bibliotheken.