Hi! Ich schreibe python in vim, vim-ale ist aktiv und das wiederum ruft alle linter dieser Welt auf um mir zu sagen wenn ich etwas schreibe was nicht pythonisch ist. Einer dieser Linter meckert völlig übliche Variablennamen wie i für die Schleifenvariable kurzer Schleifen, rc für den returncode von Funktionen und e in "except TypeError as e" an: "does not conform to snake_case style". Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig? Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Am 04.07.24 um 09:56 schrieb Marc Haber:
Einer dieser Linter meckert völlig übliche Variablennamen wie i für die Schleifenvariable kurzer Schleifen, rc für den returncode von Funktionen und e in "except TypeError as e" an: "does not conform to snake_case style".
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
Ich teile Deine Ansicht, dass die Linter hier übertreiben. Unpythonisch ist es m.E. jedenfalls nicht. Insbesondere: "does not conform to snake_case style" ist schon geradezu übergriffig- vielleicht bevorzugst Du ja camelCase?! Der Name "e" für eine Exception ist m.E. zwar etwas sehr kurz (ich verwende typischerweise "ex" oder "exp"), aber das hängt ja auch davon ab, wieviel Code im "except"-Block steckt. -- Regards Hartmut Goebel | Hartmut Goebel |h.goebel@crazy-compilers.com | |www.crazy-compilers.com | compilers which you thought are impossible |
On 2024-07-04 09:14, Hartmut Goebel <h.goebel@crazy-compilers.com> wrote:
Am 04.07.24 um 09:56 schrieb Marc Haber:
Einer dieser Linter meckert völlig übliche Variablennamen wie i für die Schleifenvariable kurzer Schleifen, rc für den returncode von Funktionen und e in "except TypeError as e" an: "does not conform to snake_case style".
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
Ich teile Deine Ansicht, dass die Linter hier übertreiben. Unpythonisch ist es m.E. jedenfalls nicht.
Insbesondere: "does not conform to snake_case style" ist schon geradezu übergriffig- vielleicht bevorzugst Du ja camelCase?!
Das kann man natürlich bevorzugen, aber solche Konventionen gehören IMHO schon zu den Dingen, die ein Linter überprüfen sollte. Wenn es also die Regel gibt, dass Variablen snake_case sein sollten, dann sollte der Linter schreien, wenn er eine in camelCase findet. Und umgekehrt, wenn man camelCase haben möchte, soll er bei snake_case schreien. Das sind relativ einfache Checks, die man einem Algorithmus überlassen kann (sofern man das auch overriden kann, dann statische Analyse kann nicht immer zwischen Klasse und Instanz unterscheiden). Aber ein einzelnes Wort sieht in camelCase (eigentlich dromedaryCase, nicht CamelCase) und snake_case (und auch kebap-case, aber das ist hier nicht relevant) immer gleich aus, also sollte der Linter hier nicht schreien. hp
Am 04.07.24 um 09:56 schrieb Marc Haber:
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist?
Meiner Meinung nach nein. Es gibt bestimmte programmiersprachenübergreifende Gepflogenheiten, die hier m.E. wichtiger sind. Ich vermute, der entprechende linter is pylint. Wie bei den meisten Python QA tools, kann man diesen über die pyproject.toml umfassend konfigurieren und bestimmte Checks pro Projekt an- und abschalten (bei manchen Tools auch pro Datei): https://pylint.readthedocs.io/en/latest/user_guide/usage/run.html#command-li... Chris
On 2024-07-04 07:56, Marc Haber <mh+python-de@zugschlus.de> wrote:
Ich schreibe python in vim, vim-ale ist aktiv und das wiederum ruft alle linter dieser Welt auf um mir zu sagen wenn ich etwas schreibe was nicht pythonisch ist.
Einer dieser Linter meckert völlig übliche Variablennamen wie i für die Schleifenvariable kurzer Schleifen, rc für den returncode von Funktionen und e in "except TypeError as e" an: "does not conform to snake_case style".
Ich halte das für einen Bug. Im Snake Case Style werden *Wörter* durch Underscores getrennt. Wenn aber ein Variablenname nur aus einem Wort besteht (und ein Buchstabe ist die Extremform von "kurzes Wort"), dann gibt es nichts, was man trennen könnte, und die Warnung ist nicht nur sinnlos, sondern schlicht falsch. Wenn man das nicht genauer konfigurieren kann, dann würde ich die Warnung abdrehen. Wenn man die Warnung nicht abdrehen kann, den Linter raustreten, Der taugt für den täglichen Einsatz nichts (er kann eventuell immer noch für Einzelüberprüfungen nützlich sein, z.B. wenn man einen Pull Request reviewt).
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
PEP 8 (ist zwar nur für die Python Library verbindlich, kann aber wohl als Definition von "pythonisch" gelten) sagt nichts über minimale Variablenlängen. Nur: | Function names should be lowercase, with words separated by | underscores as necessary to improve readability. | | Variable names follow the same convention as function names Und: | Never use the characters ‘l’ (lowercase letter el), ‘O’ (uppercase | letter oh), or ‘I’ (uppercase letter eye) as single character variable | names. Andere einbuchstabigen Variablennamen sind also offenbar ok. hp
Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
PEP 8 (ist zwar nur für die Python Library verbindlich, kann aber wohl als Definition von "pythonisch" gelten) sagt nichts über minimale Variablenlängen. Nur:
| Function names should be lowercase, with words separated by | underscores as necessary to improve readability. | | Variable names follow the same convention as function names
Und:
| Never use the characters ‘l’ (lowercase letter el), ‘O’ (uppercase | letter oh), or ‘I’ (uppercase letter eye) as single character variable | names. Was ja auch sinnvoll ist, da je nach verwendetem Font eine Unterscheidung des Buchstaben 'l' von der Ziffer '1', bzw. Buchstabe 'O' von Ziffer '0' nicht möglich ist.
-- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
On 2024-07-04 10:42, Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
Peter J. Holzer <hjp-usenet4@hjp.at> wrote:
PEP 8 [...] | Never use the characters ‘l’ (lowercase letter el), ‘O’ (uppercase | letter oh), or ‘I’ (uppercase letter eye) as single character variable | names. Was ja auch sinnvoll ist,
Hat niemand bestritten.
da je nach verwendetem Font eine Unterscheidung des Buchstaben 'l' von der Ziffer '1', bzw. Buchstabe 'O' von Ziffer '0' nicht möglich ist.
Diese Begründung steht auch gleich im nächsten Satz. Ich habe das aber nicht mitzitiert, weil ich es für selbstverständlich gehalten habe. hp
Marc Haber <mh+python-de@zugschlus.de> wrote:
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
Das ist jetzt keine echte Antwort auf deine Frage. Meine generelle Meinung dazu ist, dass Analysetools sehr hilfreich sein können, man sich aber nicht von ihnen versklaven lasssen sollte. Gruß, Enrik
On Thu, Jul 04, 2024 at 09:52:55AM -0000, Enrik Berkhan wrote:
Marc Haber <mh+python-de@zugschlus.de> wrote:
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
Das ist jetzt keine echte Antwort auf deine Frage. Meine generelle Meinung dazu ist, dass Analysetools sehr hilfreich sein können, man sich aber nicht von ihnen versklaven lasssen sollte.
Leider kann man manche dieser Tools nicht oder nur unzureichend konfigurieren. Ich habe die derzeit alle auf maximale Schärfe eingestellt weil Python für mich immer noch "Neuland[tm]" ist und ich die Kommentare als wertvollen Input sehe. Aber so pragmatisch wie shellcheck(1) scheint keins der python-Tools vorzugehen. Bei shellcheck kann man als Kommentare "getarnte" Pragmas schreiben und ihm damit mitteilen "In der näcshten zeile wirst Du das und das anzumeckern haben, lass das für diese Zeile mal, das will ich da so". Besonders anstrengend finde ich black(1), da bleibt via vim-ale nur noch ein "black would make changes" über. Grüße Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
On 2024-07-04 10:39, Marc Haber <mh+python-de@zugschlus.de> wrote:
On Thu, Jul 04, 2024 at 09:52:55AM -0000, Enrik Berkhan wrote:
Marc Haber <mh+python-de@zugschlus.de> wrote:
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig? [...] Besonders anstrengend finde ich black(1), da bleibt via vim-ale nur noch ein "black would make changes" über.
Black ist doch ein Formatierer und kein Linter, oder? hp
Naja, wenn ich I oder l oder halt i sehe, bin ich dem Linter schon dankbar :) Manchmal hinterfragt man sich auch, warum man eigentlich eine Schleife so braucht. pylint ist ganz gut konfigurierbar wie Chris schreibt Grüße Reimar On Thu, Jul 4, 2024 at 11:01 AM Marc Haber <mh+python-de@zugschlus.de> wrote:
Hi!
Ich schreibe python in vim, vim-ale ist aktiv und das wiederum ruft alle linter dieser Welt auf um mir zu sagen wenn ich etwas schreibe was nicht pythonisch ist.
Einer dieser Linter meckert völlig übliche Variablennamen wie i für die Schleifenvariable kurzer Schleifen, rc für den returncode von Funktionen und e in "except TypeError as e" an: "does not conform to snake_case style".
Ist das wirklich unpythonisch? Muss ich wirklich return_code oder ex_ception schreiben damit der linter zufrieden ist? Oder ist mein Bauchgefühl, dass diese Meldung einfach "drüber" ist, richtig?
Grüße Marc
--
----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 _______________________________________________ python-de Mailingliste -- python-de@python.org Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an python-de-leave@python.org https://mail.python.org/mailman3/lists/python-de.python.org/ Mitgliedsadresse: rb.proj@gmail.com
participants (7)
-
Christopher Arndt -
Enrik Berkhan -
Hartmut Goebel -
Marc Haber -
Peter Heitzer -
Peter J. Holzer -
Reimar Bauer