Verständnis zu type Literal

[rogerb]

@Erhy,

Mit der Einstellung:
"python.analysis.typeCheckingMode": "strict"

wird der Fehler bei mir jetzt auch angezeigt. Dazu kommen aber auch noch einige andere Probleme. Daher muss dies nicht die Ursache für die Fehlermedlung sein.
Es gibt da auch noch viele andere ähnliche Einstellungen.

Wie ja schon von allen festgestellt wurde, kann PIL eigentlich mit jedem String umgehen. Hat aber eine Sonderbehandlung für ["1", "L", "I", "P", "F", "RGB"]
In allen anderen Fällen versucht PIL.Image so gut es geht aus dem Array ein Bild zu erzeugen.
Mit "1;16" kommt PIL deswegen klar, weil das numpy Array eben sinnvolle Daten enthält.

Wenn dich die Fehlermeldung stört, müsstest du wahrscheinlich mal deine Einstellungen in VS Code prüfen. Am Code etwas zu ändern macht meiner Meinung nach keinen Sinn, da du nun mal ein "I;16" Format hast.
Wenn du statt dessen das Format "SupertollesBild" als String übergibst, wird bestimmt das gleiche dabei rauskommen.

Edit:
Mit dieser Einstellung bekomme ich genau dein Fehlerbild:
"python.analysis.typeCheckingMode": "basic"

Wie gesagt, das muss es nicht sein, sieht aber so aus. Du must dir halt überlegen wie streng du das einstellen willst.

[__blackjack__]

@rogerb: Mein Beispiel entspricht dem Code der bei Erhy zu dieser Fehlermeldung führt. Ich habe nicht „gezielt falsch programmiert“, sondern einfach nur genau das nachgestellt was in der Kombination von PIL, VS Code, und pylance, was seinerseits typeshed verwendet, Stand der Dinge ist und zu der Fehlermeldung führt.

Und all die Informationen hatte Erhy ja auch schon über mehrere Beiträge verteilt geliefert.

Was man am Code machen kann ist den Wert zu ”casten”, oder einen Kommentar hinzufügen der pylance an der Stelle ruhig stellt, oder man schaltet das mit den Typannotationen grundsätzlich aus.

[pillmuncher]

Type Annotations in Python sollten IMO nicht für statische Typabsicherung verwendet werden. Letzteres halte ich für völlig anti-pythonisch. Man kann sie aber gut für typ-basierten dynamischen Dispatch oder Property Based Testing und ähnliche Sachen verwenden.

[rogerb]

@__blackjack__,

Du hast etwas programmiert was den gleichen Fehler erzeugt.
Es ist offensichtlich etwas anderes, ob die Typeannotations im Code oder in einm Stub file vom typeshed repository liegen. Denn dort unterliegen sie den Einstellungen von Pylance.
Bei deinem Codebeispiel wird der Fehler immer angezeigt. Damit kannst du zwar den gleichen Fehler erzeugen, das beantwortet aber nicht die Frage, warum der Fehler bei Erhy auftritt, bei mir aber zum Beispiel nicht.
Erhy's Code enthielt ja keine expliziten Typeannotations. Das ist nunmal der Unterschied.

[__blackjack__]

@rogerb: Ich hätte das auch in eine Stub-Datei auslagern können, das Ergebnis wäre das gleiche gewesen. Da ist kein wirklicher Unterschied was den Effekt angeht, und die Lösung ist auch in beiden Fällen gleich.

[rogerb]

@__blackjack__,

bei Erhy entstand die Fehlermeldung, *ohne* dass Hinzufügen irgendwelcher Typeannotations. Wenn du also Typeannotations erstellst, wie auch immer, tritt die Fehlermeldung auf, aber nicht aus dem gleichen Grund wie bei Erhy sondern, weil du es durch das Hinzufügen von Typeannotations provozierst. Also gleicher Effekt aber unterschiedliche Ursache.
Denn damit hast du gezeigt, dass man durch das Hinzufügen von Typeannotations die gleiche Fehlermeldung hervorrufen kann.
Das beantwortet aber nicht die Frage wo die Fehlermeldung bei Erhy's Code herkommt wenn man *keine* Typeannotations hinzufügt.
Wie sich gezeigt hat, ist eine mögliche Ursache die Einstellung "python.analysis.typeCheckingMode" auf "basic" zu setzen, denn dann wird die Fehlermeldung angezeigt, auch wenn explizit keine Typeannotations hinzugefügt wurden.
Damit kann ich auf meinem System jedenfalls genau das von Erhy beschriebene Verhalten nachstellen und das beantwortet meine Frage.

So, die Möglichkeiten die Fehlermeldungen zu verhindern sind natürlich vielfältig. Du hattest ja auch schon einige aufgezählt. Wie du das durch einen Cast lösen willst kann ich mir allerdings nicht vorstellen. Kannst du ja mal zeigen.

Meiner Meinung nach liegt das Problem darin, dass PIL.Image eben sehr wohl I;16 verarbeiten kann, im typeshed stub für PIL.Image I;16 aber nicht als valider Typ aufgeführt ist.
Das typeshed github repository weist auch gerade für pillow eine Reihe von Pull Requests aus den letzten Wochen auf.
https://github.com/python/typeshed/pull ... Apr+pillow
Daher würde ich mal sagen, dass da noch einiges in Bewegung ist.

Empfehlung an @Erhy wäre also ein Pull Request ins typeshed repository:
https://github.com/python/typeshed/blob ... /Image.pyi
Oder man kann es ja auch selber lokal ändern. Die Stelle hatte @Erhy ja schon gefunden

[__blackjack__]

@rogerb: Oh, man das war doch alles schon geklärt das es da eben doch Typannotationen gibt. Halt nicht im Quelltext von PIL, aber Erhy hatte im *zweiten* Beitrag doch bereits die `Image.pyi` per Debugger gefunden, wo der Code/die Annotationen drin stehen, was ich nachgestellt habe. Ich habe da also nicht wie behauptet irgendwie Code erfunden der den Fehler provoziert, sondern einfach nur nachgestellt was da passiert. Und ja, ich habe dabei den Zwischenschritt ausgelassen Code ohne Annotationen zu schreiben und die Annotationen in eine Stub-Datei auszulagern. Dieser Schritt ändert doch aber nichts daran warum der Fehler zustande kommt, und auch nicht wie man da letztlich mit umgehen kann.

`typing.cast()` funktioniert, allerdings muss man dafür einen Namen mit führenden Unterstrich verwenden, was natürlich auch ein bisschen blöd ist, oder man casted einfach nach `Any`. Also:

Code: Alles auswählen

    new_image = Image.fromarray(..., cast("PIL.Image._Mode", old_image.mode))

    # oder

    new_image = Image.fromarray(..., cast(Any, old_image.mode))

    # oder

    new_image = Image.fromarray(..., old_image.mode)  # type: ignore[arg-type]

[rogerb]

@__blackjack__,

Code: Alles auswählen

... Halt nicht im Quelltext von PIL ... 

das ist aber nun mal der wichtige Unterschied. Grund: mal unterliegt es den Einstellungen von Pylance und mal nicht.
Der Grund dafür dass der Fehler bei Erhy auftritt und bei mir nicht liegt in den Einstellungen von Pylance. Das hab ich jetzt auch schon zig mal geschrieben, aber du willst es wahrscheinlich gar nicht akzeptieren. Dann ist es halt so. Ich habe jedenfalls die Antwort auf meine Frage gefunden.
Um gleich eins vorweg zunehmen: Nein, dass es an den Einstellungen "python.analysis.typeCheckingMode" liegt wurde von Niemand erwähnt.

[__blackjack__]

@rogerb: Ich will nicht aktzeptieren das es nur daran liegt und das Du mir hier Vorwürfe wie: „Dass man das gezielt falsch programmieren kann ist klar.“ machst. Ich habe da nichts gezielt falsch programmiert, sondern nur nachgestellt was tatsächlich passiert, und das halt mit Abkürzungen und Auslassungen die nichts am Problem ändern. VSCode habe ich übrigens auch komplett raus gelassen, weil ich das für irrelevant halte, denn wenn man ein Werkzeug zur Typprüfung mittels Typannotationen verwenden, dann bekommt man halt diese Meldung. Und ja, natürlich kann man die Typprüfung auch abstellen, das hast Du als einziger erwähnt.

[Erhy]

Jetzt hatte ich Erfolg durch Deinstallation und Neuinstallation von Pillow und dem Löschen von
... .vscode\extensions\ms-python.vscode-pylance-2021.9.1\dist\typeshed-fallback\stubs\Pillow .

Jetzt gibt es keine Warnung mehr für dieses Problem.

Erhy

[rogerb]

@__blackjack__,
Ich habe dir nichts vorgeworfen. Auch wenn du das so interpretieren willst. Ich habe nur gesagt, dass dein Beispiel zwar die Fehlermeldung zeigt aber aus einer anderen Ursache. Daher bringt das halt nichts um der Fehlermeldung von VS Code / Pylance auf den Grund zu gehen.
Wenn du jetzt sagst du wolltest gar nichts zu VS Code sagen, dann frage ich mich warum du meine Frage überhaupt kommentiert hast. Das ist nämlich genau der Punkt den ich Erhy gefragt hatte und der mich eben sehr wohl interessierte.
Aber ich muss dass auch nicht verstehen...

[Erhy]

war von dem Hexenwerk um Pylance rundherum sehr irritiert.
Habe auch bei Pylance gepostet: https://github.com/microsoft/pylance-re ... ssues/1798
und dann noch bei typeshed : https://github.com/python/typeshed/issues/6027

Dazu kam, dass ich in Python noch nie mit spezifizierten Typen kodiert habe.

Alles Gute
Erhy

[rogerb]

@Erhy,

die Antwort von typeshed "Das ist Absicht" ist ein wenig unbefriedigend. Ich finde schon, dass es da eine Diskrepanz zu Pillow gibt, aber das sehen sie wohl anders.
Aber du hast es ja jetzt behoben.

[__blackjack__]

@rogerb: Mein Beispiel zeigt genau die Fehlermeldung aus genau der Ursache: Die Typannotationen die nicht so richtig zusammenpassen vom `Image.mode` und dem `mode`-Argument der betroffenen Funktion. Und die Frage hat für mich deswegen mit VS Code nichts zu tun, weil sie unabhängig davon ist. Die Frage war eine Verständnisfrage zum `Literal`-Type und das hat nichts mit VSCode zu tun, sondern mit Typannotationen, und ob man nun pylance oder mypy oder das Ding von Facebook, oder welchen Editor oder welche IDE zum prüfen der Typen man verwendet, ändert nichts an der Bedeutung von `Literal`. Und eine Antwort „dann schalt halt Typprüfung aus“, nützt beim Verständnis von `Literal` auch nicht viel.

[rogerb]

@__blackjack__,

also gut, fange wir halt wieder von vorn an.
Erhy hatte zwei Code-Blöcke gepostet, die sahen so aus:

Code: Alles auswählen

from PIL import Image

origPil = Image.open( filename )
origPil_mode = origPil.mode # ist 'I;16' für ein Image mit 16-bit Auflösung
img_array = np.asarray(origPil)

Code: Alles auswählen

img_to_show = Image.fromarray( img_array , mode = origPil_mode ) # mode is defined as lieral ?
from PIL import ImageShow
ImageShow.show(img_to_show)

Damit hatte ich versucht den Fehler bei mir nachzustellen, bekam aber keine Fehlermeldung.
Darauf hatte ich Erhy gefragt, wie sich die Fehlermeldung genau in VS Code bemerkbar macht, da ich den Fehler eben bei mir nicht nachstellen konnte.

Dann hab ich irgendwann gemerkt, dass man einfach
"python.analysis.typeCheckingMode": "basic"
setzen muss um den Fehler zu bekommen und die Sache war klar:

"python.analysis.typeCheckingMode": "off" - Keine Fehlermeldung
"python.analysis.typeCheckingMode": "basic" - Fehlermeldung

Damit war meine Frage beantwortet, denn ich konnte mit Erhy's Code den Fehler nachstellen.

Dein Bespiel zeigt die gleiche Fehlermeldung. Ich wollte aber verstehen, warum der Fehler bei Erhy's Code auftritt.
Meine Frage war immer nur warum der Fehler bei ihm auftritt, bei mir aber nicht. Das hast du bis jetzt nicht beantworten können, wolltest du ja auch anscheinen gar nicht und ist ja auch gar nicht mehr nötig.

[Erhy]

bei mir ist
"python.analysis.typeCheckingMode": "basic" und
"pylance.TypeChecking mode": "basic" gesetzt und es kommt trotzdem keine Warnung mehr.

Die Pillow Leute meinten, sie haben in der neuen Version keine stubs hinzugefügt.
So müssen die fehlerhaften Prototypes von älteren Versionen von Pillow stammen.

Wie schon erwähnt nach Bereinigung der gespeicherten Stubs von Pillow und Neuinstallation von Pillow tritt der Fehler nicht mehr auf.

[narpfel]

@Erhy: Das hört sich so an, als hättest du die Stubs jetzt einfach deinstalliert? Das ist IMHO die schlechtestmögliche Lösung, ein `# type: ignore` oder ein `cast` hätte das Problem auch gelöst und du hättest die Type Hints im Rest vom Code weiter benutzen können.

[rogerb]

@narpfel,

die Stubs werden automatisch neu heruntergeladen sobald die Python Extension für VS Code installiert wird.

[rogerb]

@Erhy,

Die Einstellung "pylance.TypeChecking mode": "basic" gibt es bei mir nicht. Wie hast du das eingestellt?

[Erhy]

habs nur intuitiv erwähnt, hier genauer:
"python.analysis.typeCheckingMode": "basic"

ist ein rechter Durcheinander - die Option wird unter Pylance gelistet und die Referenz zeigt auf Python