pyLint und reimport warning

[jkalden]

Moin!

Ich habe folgendes Problem: Am Beginn meines Scripts importiere ich als erstes zwei Scipy-Submodule und pylab:

Code: Alles auswählen

import pylab as pl
import scipy.io
import scipy.interpolate

Egal, in welcher Reihenfilge ich die importiere, beschwert sich pyLint immer über den letzten Import, im obigen Fall also

Code: Alles auswählen

W0404: 18: Reimport 'scipy.interpolate' <imported line 16>

Kennt jemand das Problem, oder vielleicht sogar die Lösung? Ignorieren ist leider keine Option... Danke!

[BlackJack]

@jkalden: 1. Kann ich nicht nachvollziehen.

2. Zeig doch mal den tatsächlichen Quelltext, also da wo für Zeile 18 die Warnung kommt und was dort dann in Zeile 16 steht, oder alternativ ein minimales Beispiel mit der tatsächlich dazugehörigen Pylint-Meldung.

3. Wieso ist ignorieren keine Lösung? Bei einer dynamischen Programmiersprache wird man immer das Problem haben dass ein „lint”-Programm entweder zu lasch ist und bestimmte Probleme nicht findet, oder Probleme meldet, die gar keine sind. Pylint erlaubt es deshalb mit speziellen Kommentaren einzelne Konstrukte aus der Prüfung beziehungsweise den Meldungen explizit auszunehmen.

[jkalden]

@BlackJack:

ad 1, 2: Du siehst die Zeilen 16 - 18. Davor kommt nur ein Kommentar mit Erläuterungen zur Benutzung (Zeilen 1 - 15, hier irrelevant). In Folge dessen verstehe ich unter den 3 Zeilen bereits ein Minimalbeispiel. den kompletten Code (> 1000 Zeilen) kann und möchte ich nicht hier posten.

ad 3: Ignorieren ist keine Lösung, weil der Abnehmer über ein pylintrc festgelegt hat, was er ignoriert, und diese Meldung wird eben nicht ignoriert.

[BlackJack]

@jkalden: Da Pylint nicht unfehlbar ist, *muss* Ignorieren auch als Lösung in Frage kommen. Sonst verlangt der Abnehmer etwas unmögliches oder etwas das sinnfreie Umgehungslösungen nötig macht, die letztendlich umständlicher und vielleicht sogar fehlerträchtiger sind, als gezielt einzelne Vorkommen von Meldungen zu ignorieren. Ein Programm *unnötig* komplexer zu machen um einer Formalie zu genügen und dabei deren Sinn zu karikieren kann ja nicht das Ziel sein.

Und wie gesagt ich kann das Problem bei mir nicht nachvollziehen. Also entweder ist das ein Fehler in Deiner verwendeten `pylint`-Version oder Deine `scipy`-Version macht mehr ``import``-„Voodoo” als meine und als Dein `pylint` verträgt.

[jkalden]

Ich verwende das pylint, das bei pythonxy 2.7.2 für Windows dabei ist. Wenn ich das richtig gesehen habe, ist das Version 0.23! Mir ist klar, dass es keine "fertige" Version ist, aber es bildet die baseline für meinen Abnehmer.

Für mich entsteht folgender Eindruck:
Der Konflikt ergibt sich aus pylab und den scipy imports. Offensichtlich interferieren die. Und ich hatte mich gefragt, wie das kommt und ob es einen pythonic way gibt, den Konflikt aufzulösen. Ich habe noch nicht probiert, ob die Variante der expliziten Importe ( from foo import bar ) die Fehlermeldung verhindert, das versuche ich, wenn ich wieder dran sitze. Aber eigentlich mag ich es wegen der Übersicht lieber, nur die Packages zu importieren.

Das Skript an sich tut was es soll. Der Abnehmer fügt es in ein relativ komplexes Software-System ein, was er anschließend unter anderem mit pylint prüft. Wenn jetzt jeder Contributor eine Ausnahmeregelung wünscht, kommt man halt irgendwann in Teufels Küche, da hab ich schon Verständnis für.

Mal sehen, ob ich eine Lösung, vor allem aber eine Erklärung für das seltsame Verhalten finde.

[BlackJack]

@jkalden: Ob das eingesetzte `pylint` eine fertige Version ist oder nicht spielt keine Rolle, jedes statische Prüfwerkzeug für dynamische Sprachen wie Python ist entweder zu „lasch” oder wird bei irgendwelchem Quelltext auf „false positives” treffen und etwas anmahnen was kein Problem darstellt oder am Ende überhaupt nicht stimmt.

Was meinst Du mit Teufels Küche? Wenn Leute die Code beisteuern abenteuerliche Stunts hinlegen, nur weil man keine „false positives” von `pylint` im Quelltext unterdrücken darf, ist man nicht in Teufels Küche? Da wird Zeit versenkt um zusätzlichen Code zu schreiben, der Probleme umgeht, die gar keine sind. Nur um eine starre, bürokratische Vorgabe zu erfüllen, deren Sinn und Zweck damit am Ende ins Gegenteil verkehrt wird. Da habe ich überhaupt kein Verständnis für!

Und wo ist eigentlich der Nachteil das vorkommen einer konkreten „false positive”-Meldung durch einen speziellen Kommentar zu unterdrücken, statt es durch zusätzlichen, eigentlich unnötigen Code zu tun? Ausser das letzteres mehr Zeit kostet und man eventuell zusätzliche Fehlerquellen einbaut‽

[jkalden]

@BlackJack:

Die expliziten Importe haben mein Problem gelöst. Pylint ist anscheinend darüber gestolpert, dass sowohl pylab als auch die scipy-subpackages gleichnamige Funktionen bereitstellen. Halte ich eher für einen bug, man muss ja den Paketnamen immer mitführen, das schließt Verwechslungen aus.

Über Sinn und Unsinn von Vorgaben kann man immer trefflich streiten, aber ab einer gewissen Projektgröße muß man einfach Vorgaben machen, an die sich alle zu halten haben. Daraus entstehende Konflikte muss man eben hinnehmen...

Danke trotzdem für deine Denkanstöße!

[Leonidas]

Über Sinn und Unsinn von Vorgaben kann man immer trefflich streiten, aber ab einer gewissen Projektgröße muß man einfach Vorgaben machen, an die sich alle zu halten haben. Daraus entstehende Konflikte muss man eben hinnehmen...

Das ist doch Quatsch. Das würde heißen dass große Projekte zwangsläufig schlechter werden, weil die Vorgaben immer bizarrer werden. Wie etwa das in jedem Variablennamen der Buchstabe ö vorkommen muss. Eine Projektleitung die sowas zulässt ist... naja.

[BlackJack]

@jkalden: In diesem Fall könnte der Abnehmer die Vorgabe aber *ganz einfach* so abändern, dass kein schlechterer Code entsteht. Wie man dafür Verständnis haben kann verstehe ich nicht. Ich wüsste auch immer noch wo man da in Teufels Küche kommt, wo dieses massive Problem ist, und für wen eigentlich, wenn man in begründeten Fällen das Unterdrücken einzelner Vorkommen von Meldungen erlaubt. Der Abnehmer bekommt saubereren Code ohne zusätzliche Umgehungslösungen und der Zulieferer braucht diese zusätzlichen Umgehungslösungen nicht implementieren. Wer verliert denn bitte etwas in diesem Szenario? Ich sehe da nur zwei Gewinner.

Edit: Ich persönlich würde es wahrscheinlich einfach *machen* und warten ob und was der Abnehmer dazu sagt. Denn ich kann die Entscheidung vertreten und begründen.

[jkalden]

Ich habe es eben einfach über die Variante "from foo import bar" gelöst. Ich muss nix verhandeln, mein code tut dasselbe und ist nicht komplizierter geworden, und pylint bleibt stumm.

Ihr braucht nicht zu glauben, dass ich solche Vorgaben für sinnvoll halte... Ich halte lediglich meine Lösung für die einfachste!

[BlackJack]

@jkalden: Ich behaupte mal Du hast da mehr Zeit für investiert als einen Kommentar an die Problemzeile zu schreiben. Dann ist Deine Lösung nicht die einfachste.

[jkalden]

@BlackJack: Hätte ich den Kommentar geschrieben, hätte ich nicht verstanden, was pylints Problem ist. Unter Berücksichtigung meiner Lernkurve war es dann die effektivste Lösung und vielleicht nicht die "einfachste". Es ist manchmal toll, Probleme nicht mit dem erstbesten "Hammer zu erschlagen", sondern zu verstehen, wo es denn hängt. Beim nächsten Mal kann ich die Kommentarvariante benutzen, wenn es dereinst die Vorgaben hergeben...

Damit sollte es hier aber auch wirklich gut sein!