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:
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:
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 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).
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
On 2024-07-04 10:42, Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
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
On Thu, Jul 04, 2024 at 09:52:55AM -0000, Enrik Berkhan wrote:
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
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:
Am 04.07.24 um 09:56 schrieb Marc Haber:
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:
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 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).
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
On 2024-07-04 10:42, Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> wrote:
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
On Thu, Jul 04, 2024 at 09:52:55AM -0000, Enrik Berkhan wrote:
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
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:
participants (7)
-
Christopher Arndt -
Enrik Berkhan -
Hartmut Goebel -
Marc Haber -
Peter Heitzer -
Peter J. Holzer -
Reimar Bauer