[Gelöst] Warum akzeptiert Python bei with open("datei", "w") nur str() und kein int() ?

  • Der Titel sagt ja schon alles.

    Warum akzeptiert Python nur str() und kein int(), wenn ich mit with open("datei", "w") in eine Datei schreiben will ? :denker:

    Also z.B.:

    Code
    with open("/dev/shm/check.txt", "w") as check:
        check.write("1")

    und

    Code
    test = int(psutil.cpu_percent(5))
    with open("/dev/shm/datei.txt", "w") as datei:
        datei.write(str(test))

    Aber nicht als datei.write(int(test)) :conf:

  • fred0815

    Changed the title of the thread from “Warum akzeptiert Python bei with open(datei, w) nur str() und kein int() ?” to “Warum akzeptiert Python bei with open("datei", "w") nur str() und kein int() ?”.
  • Hallo fred0815,


    sollte es daran liegen, dass Python keine implizite Typumwandlung kennt?


    Beste Grüße aktuell aus Minga


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • fred0815 Na eben genau deswegen, weil Python nicht einfach Typen implizit umwandelt. In eine Textdatei kann man Text schreiben und keine Zahlen. Wenn Du *irgendwas* in eine Textdatei schreiben willst, musst Du das in Text umwandeln.

    “The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.” — Nathaniel Borenstein

    • Official Post

    Die Doku sagt dazu folgendes:

    f.write(string) writes the contents of string to the file, returning the number of characters written.

    Code
    >>>>>> f.write('This is a test\n')
    15

    Other types of objects need to be converted – either to a string (in text mode) or a bytes object (in binary mode) – before writing them:

    Code
    >>>>>> value = ('the answer', 42)
    >>> s = str(value) # convert the tuple to string
    >>> f.write(s)
    18
  • fred0815

    Changed the title of the thread from “Warum akzeptiert Python bei with open("datei", "w") nur str() und kein int() ?” to “[Gelöst] Warum akzeptiert Python bei with open("datei", "w") nur str() und kein int() ?”.
  • fred0815 Python ist stark typisiert. Es mag umständlich erscheinen, aber es beugt auch Fehlern vor. Du kannst nicht aus versehen etwas in eine Textdatei schreiben was Du vergessen hast in eine Zeichenkette umzuwandeln, nur um dann später festzustellen, das Du statt eines Wertes das GUI-Element aus dem Du das eigentlich auslesen wolltest in eine Datei geschrieben hast. Das kann man ja auch in eine Zeichenkette umwandeln, aber die `repr()`-Form von so etwas ist halt nicht zu gebrauchen. Also ausser bei der Fehlersuche um zu sehen was das ist.


    Und beim einlesen geht es halt gar nicht. Wenn Du da ``foo = next(text_file)`` stehen hast, woher sollte Python denn bitte wissen ob `foo` jetzt die eingelesene Zeichenkette sein soll, oder ob Du da auf magische Weise eine ganze Zahl haben willst? Oder vielleicht eine Gleitkommazahl? Oder etwas ganz anderes.


    Implizite Typumwandlungen wären unpythonisch. Aus dem „Zen of Python“ (``import this``): „Explicit is better than implicit“ und „In the face of ambiguity, refuse the temptation to guess.“

    “The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.” — Nathaniel Borenstein

  • Hallo,


    Quote

    Finde ich umständlich, eine Zahl zu str() machen zu müssen und beim auslesen wieder als int(), aber nun gut, erledigt.

    Na ja, woher soll Python denn wissen, ob du jetzt wirklich eine Zahl schreiben und lesen willst und nicht einen String? Wenn Python (oder andere Sprachen, die dynamisch stark typisiert sind) für dich das "Raten" würde, kämen im ungünstigsten Fall so Sachen raus wie bei dynamisch schwach typisierten Sprachen, siehe oben.


    Gruß, noisefloor

  • Finde ich umständlich, eine Zahl zu str() machen zu müssen und beim auslesen wieder als int(), aber nun gut, erledigt.

    Mit str formatting braucht man das nicht.



    Mit einem aktuellen Debian braucht man sich auch keine Gedanken machen, ob f-strings unterstützt werden oder nicht.

    Python 3.6 ist EOL, f-strings wurden mit 3.6 eingeführt und Debian Buster setzt auf Python 3.7. An Python 2.7 braucht man nicht mehr zu denken.


    https://pyformat.info/

  • Unfug, das gab's als backport auch in Python 2.7 und sogar 2.6 (nicht, dass das jetzt noch eine Rolle spielt...):


    Ist mir bekannt, aber nicht erwähnenswert und für das Forum auch nicht so wichtig.


    Ich schrieb:

    An Python 2.7 braucht man nicht mehr zu denken.


    Python 2.7 ist EOL und wer immer noch Python 2.7 nutzt, hat ein Problem mit der Sicherheit.

    Deswegen schreibe ich nicht, was man machen kann, sondern was man nicht mehr machen soll.

    Das hat didaktische Gründe.

  • Du schriebst aber auch "ab Python 3.0" und erwähnst unter "Python 2.7" nur percent-formatting - warum??!!

    Schrieb ich doch: Aus didaktischen Gründen.

    Gegenfrage: Wieso sollte ich Anfänger mit Information belasten, die für sie einfach nicht relevant sind.

    Portieren Anfänger neuerdings Python 2.7 Programme nach Python 3?

    Fangen Anfänger mit Python 2.7 an?

  • Hallo,


    DeaD_EyE: sieh' es mal so. Die Aussage in deinem Post "ab Python 3.0" bezogen auf die format-Methode ist halt falsch. Immer. Jetzt, 2022, 2010, 2009. Auch dann noch, wenn wir in 20 Jahren Python 6.8 verwenden.

    Die format-Methode gibt es ab Python 2.6. Und dabei ist es relativ egal, dass Python 2.6 und 2.7 EOL ist.


    Das Internet ist voll mit schlechten und falschen Info (u.a. zu Python), da müssen Post in diesem Forum nicht noch weiter zu beitragen.


    Gruß, noisefloor

  • hyle

    Closed the thread.