Python rechnet falsch

Und wie funktioniert das? HAb da keinen Plan

STK500-Besitzer schrieb:
> Scheint ein String-Verarbeitungs-Problem zu sein.
> Deine Eingabe ist ein Text.
> So wie ich es interpretiere, verfielfacht Python diesen String einfach
> 24 Mal.
> Du musst den String also in eine Zahl umwandeln.

Das ist kein Problem, sondern intendiert und dokumentiert:

1

3 * '4'

ist in Python tatsächlich '444', anstatt (wie in PHP) 12.

1

3 + '4'

dagegen ist in PHP 7, in Python wirft das einen TypeError.

Marvin K. schrieb:
> tage = float();
> tage = input();
> stunden = float();

Den "float()"-Quatsch kannst Du Dir in Python sparen, die Semikola am 
Ende der Zeilen ebenfalls. Python verwendet Autovivikation -- Du mußt 
Variablen also nicht deklarieren -- und andererseits bindet es Typen 
nicht an die Variablen, sondern an den Wert. Beispiel:

1

i = 3    # i ist jetzt ein integer

2

i = 3.3  # i ist jetzt ein float

3

i = '3'  # i ist jetzt ein str (in Python2) oder ein bytes (Python3)

Diesen Code kannst Du genau so ausführen, und der Typ von i ändert sich 
dabei mit jeder Zuweisung.

Leider ist mein ursprünglicher Post-Versuch genau in die Minute 
gefallen, als das Topic kurz weg war...

Kurz: Python ist Typenschwach, eine Variable, die vorher einen string 
enthilt, kann mit nächster Zuweisung einen int oder float enthalten, und 
umgekehrt.

Zugleich hat Python mächtige Array-Funktionen. Da strings nichts anderes 
als Arrays sind, kannst du deren Elemente multiplizieren, es passiert 
also folgendes:

'5' * 2 = '55'

5 * 2 = 10

[5] * 2 = [5, 5]

float('5') * 2 = 10

Das ist alles so gewollt. Für Anfänger verwirrend, aber nützliche 
Features.

Edit: Missverständlichkeit reduziert

Chris R. schrieb:
> Kurz: Python ist Typenschwach

Verzeihung, PHP ist schwach typisiert, weil es sich seinen Variablentyp 
je nach verwendetem Operator automatisch zurecht castet -- und deswegen 
kommt dort bei 3 + '4' auch 7 heraus, bei 3 * '4' eine 12.

Python ist dynamisch, aber stark typisiert, deswegen wirft es bei 3 + 
'4' einen TypeError. 3 * '4' ist dagegen unter Python definiert (durch 
die "magische" Methode _mul_ des Builtin 'str'), heraus kommt '444'.

Sheeva P. schrieb:
> Python ist dynamisch, aber stark typisiert

sorry, da hab ich was durcheinander geworfen - danke für die 
Berichtigung! :)

imonbln schrieb:
> (Zur Vereinfachung wurde die Fehlerbehandlung weglassen)

Das scheint ein weit verbreitetes Motto bei Python Programmierern zu 
sein. ;-)

Chris R. schrieb:
> Sheeva P. schrieb:
>> Python ist dynamisch, aber stark typisiert
>
> sorry, da hab ich was durcheinander geworfen - danke für die
> Berichtigung! :)

Nichts zu danken, sehr gerne. Im Alltag ist man an solche Dinge 
irgendwann ja so gewöhnt, daß man es als selbstverständlich hinnimmt und 
nicht mehr darüber nachdenkt... Ich hätte das sicherlich auch schon 
längst vergessen, wenn ich nicht unregelmäßig Python-Schulung halten 
würde. ;-)

Da D. schrieb:
> imonbln schrieb:
>> (Zur Vereinfachung wurde die Fehlerbehandlung weglassen)
>
> Das scheint ein weit verbreitetes Motto bei Python Programmierern zu
> sein. ;-)

Da Python meist das Richtige tut, ist das in der Regel auch überflüssig. 
;-)

Sheeva P. schrieb:
> Da Python meist das Richtige tut, ist das in der Regel auch überflüssig.
> ;-)

Du meinst "Mit nem Stacktrace abschmieren" ist das richtige für den 
User des Programms?

Da D. schrieb:
> Du meinst "Mit nem Stacktrace abschmieren" ist das richtige für den
> User des Programms?

In diesem speziellen Fall schon:

Der User ist hier einer, der gerade anfängt, in Python zu programmieren.

Für diesen dürfte die aus der Falscheingabe "Hampelmann" resultierende
Fehlermeldung

1

  File "test.py", line 3, in <module>

2

    stunden = int(tage) * 24

3

ValueError: invalid literal for int() with base 10: 'Hampelmann'

leichter zu verstehen sein als das zum Abfangen dieses Fehlers
erforderliche Exception-Handling.

MaWin schrieb:
> Test schrieb:
>> stunden = int(tage) * 24
>
> Es lebe die Typesicherheit! Jeder cast ist überflüssig, wenn man
> programmieren kann. Ein cast ist immer ein Indikator für einen
> schlechten Programmierer.

Das ist kein cast, sondern eine Konvertierung nach int.

Erwin D. schrieb:
>> Erwin D. schrieb:
>>> MaWin schrieb:
>>>> Jeder cast ist überflüssig, wenn man
>>>> programmieren kann.
>>>
>>> Dann berichtige bitte und zeig, wie man es richtig macht.
>>
>> Hat dir deine Mutti nicht gesagt, dass Du MaWin nicht überfordern
>> sollst?
>
> Das ist doch keine Überforderung.
> Das beantwortet er doch mit links ;-)

Mich würde auch interessieren, was denn seiner Meinung nach der richtige 
Weg ist, um in python einen string in einen int zu konvertieren.
Und mich würde interessieren, warum es wohl in sehr vielen Sprachen 
Casts gibt, wenn ihre Benutzung wie er behauptet grundsätzlich immer ein 
Fehler ist.

STK500-Besitzer schrieb:
> Sheeva P. schrieb:
>> Das ist kein Problem, sondern intendiert und dokumentiert:
>
> Doch ist es: Für den Threadopener ;)
> Ich habe bis jetzt keine Ahnung von python.

Das tut mir leid, aber Du kannst es ja leicht beheben. ;-)

Nein, im Ernst: wenn Du Verwendung für eine Skriptsprache hast, ist 
Python zweifellos eine hervorragende Wahl. ;-)

> Dass der TO noch andere, mehr Defizite hat, hat er ja schon geschrieben.
> python-Tutorien sollte es aufgrund seiner Verbreitung ja zuhauf geben.
> Damit würde ich anfangen.

Das ist zwar zweifellos richtig, aber als Anfänger fängt man so ein 
Tutorial ja erstmal an und verinnerlicht es nicht innerhalb von einer 
halben Stunde. Unser TO wird sicherlich noch an die richtige Stelle des 
Tutorial kommen und den entsprechenden Hinweis finden, hab' doch bitte 
einfach mal ein bisschen Geduld mit einem Einsteiger. ;-)

Da D. schrieb:
> Sheeva P. schrieb:
>> Da Python meist das Richtige tut, ist das in der Regel auch überflüssig.
>> ;-)
>
> Du meinst "Mit nem Stacktrace abschmieren" ist das richtige für den
> User des Programms?

Das hängt ganz davon ab, aber meistens ist das so. Der Stacktrace hat ja 
immerhin die Informationen, daß, warum, was, und wo etwas schiefgelaufen 
ist. Das ist mehr, als ich von vielen anderen Sprachen kenne...

Typo schrieb:
> Für Python gibt es übrigens statische type checker die bei größeren
> Projekten sinnvoll sein können.
>
> http://mypy-lang.org/
> https://google.github.io/pytype/

Und natürlich einen Linter:

https://www.pylint.org/