michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 810
|
Danke user_unknown, das ist eine sehr verständliche Erklärung, sie ist jetzt in meinem "Handbuch". Wichtig wäre jetzt m.E. noch, Deinen Code
| /usr/bin/python py.py
/usr/bin/env python
./py.py
|
für Python3 um
/usr/bin*python3 py.py
bzw. einen entsprechende Shebang zu ergänzen.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
michahe schrieb:
Wichtig wäre jetzt m.E. noch, Deinen Code
für Python3 um
/usr/bin*python3 py.py
bzw. einen entsprechende Shebang zu ergänzen.
Aber ohne den Asterix, dafür mit einem Slash! Es kommt beim Programmieren wirklich auf eine gewisse Genauigkeit an. Das solltest Du beherzigen.
|
Axel-Erfurt
Anmeldungsdatum: 18. Mai 2016
Beiträge: 1347
|
Neral schrieb: @rklm: zsh .
Die Ausgaben zeigen ja, dass type allgemeiner ist
Naja, which kann auch -a :
| $ which -a ls
ls: aliased to ls --color=tty
/usr/bin/ls
/bin/ls
|
Der -a Schalter funktioniert nicht in jedem Terminal, im xfce4-terminal zeigt es mir axel@Esprimo-P400:/tmp$ which -a ls
/bin/ls Die Ausgaben von type und command -v sind: axel@Esprimo-P400:/tmp$ type ls
ls ist ein Alias von »ls --color=auto«.
axel@Esprimo-P400:/tmp$ command -v ls
alias ls='ls --color=auto'
|
michahe
(Themenstarter)
Anmeldungsdatum: 12. Dezember 2013
Beiträge: 810
|
rklm schrieb: Aber ohne den Asterix, dafür mit einem Slash!
ja logisch, das war als Kurzform gemeint für
/usr/bin/python3 py.py
/usr/bin/env python3 py.py
|
Neral
Anmeldungsdatum: 3. Oktober 2007
Beiträge: 229
|
Axel-Erfurt schrieb: Der -a Schalter funktioniert nicht in jedem Terminal, im xfce4-terminal zeigt es mir
Das hängt nicht vom Terminal ab (wie könnte es auch, das zeigt ja nur die Ausgaben der Shell an), sondern von der Shell, die man verwendet. bash , dash und fish zeigen bei which keine Aliase an, zsh schon.
user_unknown schrieb: Du warst kurz davor und hast Dich auf den Pfad des "env" locken lassen. Schreib da den Pfad zu Python rein - der Version, die Du aufrufen willst, wenn es eine spezielle ist, prüfe ob der Pfad stimmt, der Shebang funktioniert, fertig.
Das ist problematisch, weil dann virtuelle Umgebungen nicht mehr funktionieren, und die will man in Python immer benutzen, auch (und gerade) als Anfänger, damit man sich nicht seine systemweite Python-Installation kaputt macht.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Neral schrieb: Axel-Erfurt schrieb: Der -a Schalter funktioniert nicht in jedem Terminal, im xfce4-terminal zeigt es mir
Das hängt nicht vom Terminal ab (wie könnte es auch, das zeigt ja nur die Ausgaben der Shell an), sondern von der Shell, die man verwendet. bash , dash und fish zeigen bei which keine Aliase an, zsh schon.
user_unknown schrieb: Du warst kurz davor und hast Dich auf den Pfad des "env" locken lassen. Schreib da den Pfad zu Python rein - der Version, die Du aufrufen willst, wenn es eine spezielle ist, prüfe ob der Pfad stimmt, der Shebang funktioniert, fertig.
Das ist problematisch, weil dann virtuelle Umgebungen nicht mehr funktionieren, und die will man in Python immer benutzen, auch (und gerade) als Anfänger, damit man sich nicht seine systemweite Python-Installation kaputt macht.
Gut, vielleicht bin ich, als Nicht-Python-Entwickler, hier auf dem Holzweg. Ich weiß nicht mal, was mit virtuellen Umgebungen hier gemeint ist. Ich benutze ja einige Programme, die in Python geschrieben sind aber habe da auch nie in den Quellcode geschaut. Soweit ich env kenne macht ein nacktes
als Shebang auch nichts anderes, als /usr/bin/python
unter Ubuntu. Vielleicht kannst Du mal erläutern, wie man sich die systemweite Pythoninstallation damit kaputtmachen kann und auf welche Weise env einen davor schützt. Mir scheinen da noch ein paar Annahmen mehr nötig zu sein, die nicht erwähnt wurden.
|
Neral
Anmeldungsdatum: 3. Oktober 2007
Beiträge: 229
|
@user_unknown: Man kann immer nur genau eine Version eines Python-Moduls (global) installieren. Beispiel: foo==1.2.4 wird über das Paket python3-foo mit apt installiert und ist eine Abhängigkeit von diversen Systemprogrammen, in genau dieser Version. Wenn ich als Nutzer jetzt pip3 install foo ausführe und damit eine Version installiere, die nicht mit 1.2.4 kompatibel ist, überdecke ich das mit der Paketverwaltung installierte foo und mache alle (mit der Paketverwaltung installierten) Programme kaputt, die foo benutzen. Deswegen hat Python virtuelle Umgebungen erfunden: Eine vom globalen Interpreter unabhängige Python-Installation, bei der die installierten Pakete nicht mit den Paketen vom System-Python interagieren. Da kann ich jetzt nach Belieben foo==2.0.0 , foo=0.8.5 oder was auch immer installieren, ohne dass das System-Python das sehen könnte. Das Problem daran ist, dass der Python-Interpreter dann nicht mehr /usr/bin/python3 ist, sondern /pfad/zur/venv/bin/python3 . Die virtuelle Umgebung trägt sich allerdings (temporär) in $PATH ein, sodass /usr/bin/env python3 den richtigen Interpreter findet. Man könnte natürlich auch #!/pfad/zur/venv/bin/python3 als Shebang benutzen, aber dann ist man auf genau diese eine venv festgelegt. Beispiel:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77 | /tmp/t $ cat main.py
#!/usr/bin/python3
import sys
import attr
print(sys.executable)
print(attr.__version__)
/tmp/t $ cat main_env.py
#!/usr/bin/env python3
import sys
import attr
print(sys.executable)
print(attr.__version__)
/tmp/t $ diff main.py main_env.py
--- main.py 2020-11-13 15:40:40.860684517 +0100
+++ main_env.py 2020-11-13 15:40:40.860684517 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python3
+#!/usr/bin/env python3
import sys
import attr
/tmp/t $ ./main.py
/usr/bin/python3
20.3.0
/tmp/t $ ./main_env.py
/usr/bin/python3
20.3.0
/tmp/t $ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/neral/bin:/home/neral/.local/bin:/home/neral/.cargo/bin
/tmp/t $ python3 -m venv venv
/tmp/t $ . ./venv/bin/activate
/tmp/t $ echo $PATH
/tmp/t/venv/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/neral/bin:/home/neral/.local/bin:/home/neral/.cargo/bin
/tmp/t $ ./main.py
/usr/bin/python3
20.3.0
/tmp/t $ ./main_env.py
Traceback (most recent call last):
File "./main_env.py", line 4, in <module>
import attr
ModuleNotFoundError: No module named 'attr'
/tmp/t $ pip3 install attrs==19.1.0
Collecting attrs==19.1.0
Downloading attrs-19.1.0-py2.py3-none-any.whl (35 kB)
Installing collected packages: attrs
Successfully installed attrs-19.1.0
WARNING: You are using pip version 20.2.1; however, version 20.2.4 is available.
You should consider upgrading via the '/tmp/t/venv/bin/python -m pip install --upgrade pip' command.
/tmp/t $ ./main.py
/usr/bin/python3
20.3.0
/tmp/t $ ./main_env.py
/tmp/t/venv/bin/python3
19.1.0
/tmp/t $ python3 main.py
/tmp/t/venv/bin/python3
19.1.0
/tmp/t $ deactivate
/tmp/t $ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/neral/bin:/home/neral/.local/bin:/home/neral/.cargo/bin
|
Die virtuelle Umgebung in /tmp/t/venv ist hat keinen Zugriff auf die Systempakete und umgekehrt.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12801
|
michahe schrieb: rklm schrieb: Aber ohne den Asterix, dafür mit einem Slash!
ja logisch, das war als Kurzform gemeint für
/usr/bin/python3 py.py
/usr/bin/env python3 py.py
Zum einen sind das zwei sehr unterschiedliche Dinge und zu anderen wurde das aus Deinen Beitrag nicht klar. Ich erinnere noch einmal an meine Bemerkung zur Genauigkeit.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Neral schrieb: @user_unknown: Man kann immer nur genau eine Version eines Python-Moduls (global) installieren. Beispiel: foo==1.2.4 wird über das Paket python3-foo mit apt installiert und ist eine Abhängigkeit von diversen Systemprogrammen, in genau dieser Version.
Danke für die Erklärung. Aber meinst Du, das sind Fragen, die für michahe jetzt schon relevant sind?
|
Neral
Anmeldungsdatum: 3. Oktober 2007
Beiträge: 229
|
@user_unknown: Sobald man pip benutzt, ist das IMHO relevant. Andererseits: Wenn man am Anfang einfach immer #!/usr/bin/env python3 cargo-cultet, bis man es versteht, dann funktioniert alles wie gewollt und man hat keine Nachteile. Von daher sehe ich die Empfehlung, #!/usr/bin/python3 zu nehmen, eher kritisch, weil es im Zweifelsfall Probleme macht, die man als Anfänger nicht lösen kann und die man mit env nicht hat.
|
linux-nerd
Anmeldungsdatum: 30. November 2020
Beiträge: 7
|
user_unknown schrieb: seahawk1986 schrieb: Statt Geany könnte auch Visual Studio Code einen Versuch wert sein (gibt es als Snap: https://snapcraft.io/code), der Language Server von Microsoft für Python ist ziemlich gut und Hilft grobe Fehler frühzeitig zu erkennen und die Integration des Debuggers in die GUI ist ebenfalls gut gelöst.
Ist das nicht ein bischen fett, träge und für den Anfänger überfordernd? Das ist doch sicher überfrachtet mit Einstelloptionen.
Ja, es ist ein bisschen dick, aber im Grunde ist es eine komplette IDE mit Plugin und Unterstützung für mehrere Programmiersprachen. Die IDE kann viele Vorteile für einen Anfänger haben, zum Beispiel die automatische PEP-8-Formatierung. Sie können auch VIM und Plugins im gleichen Umfang verwenden, ich persönlich benutze Pycharm, da ich keine Mehrsprachen-Unterstützung benötige.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
linux-nerd schrieb: user_unknown schrieb: seahawk1986 schrieb: Statt Geany könnte auch Visual Studio Code einen Versuch wert sein (gibt es als Snap: https://snapcraft.io/code), der Language Server von Microsoft für Python ist ziemlich gut und Hilft grobe Fehler frühzeitig zu erkennen und die Integration des Debuggers in die GUI ist ebenfalls gut gelöst.
Ist das nicht ein bischen fett, träge und für den Anfänger überfordernd? Das ist doch sicher überfrachtet mit Einstelloptionen.
Ja, es ist ein bisschen dick, aber im Grunde ist es eine komplette IDE mit Plugin und Unterstützung für mehrere Programmiersprachen.
Ja, das ist ein Nachteil, wenn man viel einstellen und viel verstellen kann. Man müsste sich vorher auskennen, um sagen zu können, was davon brauche ich eigentlich? Ein Editor mit Syntaxhighlighting und wenig Schnickschnack ist am Anfang am besten. Der in weniger als 1s startet, damit man Lust hat, ihn auch zu benutzen.
Die IDE kann viele Vorteile für einen Anfänger haben, zum Beispiel die automatische PEP-8-Formatierung.
Handformatierung ist nötig, falls man mit einem Problem nicht weiterkommt. Dann kann man die Einrückungen geradeziehen und findet die Problemlösung, weil man sich nicht mehr auf den falschen Verdacht fokussiert.
|
linux-nerd
Anmeldungsdatum: 30. November 2020
Beiträge: 7
|
user_unknown schrieb: linux-nerd schrieb: user_unknown schrieb: seahawk1986 schrieb: Statt Geany könnte auch Visual Studio Code einen Versuch wert sein (gibt es als Snap: https://snapcraft.io/code), der Language Server von Microsoft für Python ist ziemlich gut und Hilft grobe Fehler frühzeitig zu erkennen und die Integration des Debuggers in die GUI ist ebenfalls gut gelöst.
Ist das nicht ein bischen fett, träge und für den Anfänger überfordernd? Das ist doch sicher überfrachtet mit Einstelloptionen.
Ja, es ist ein bisschen dick, aber im Grunde ist es eine komplette IDE mit Plugin und Unterstützung für mehrere Programmiersprachen.
Ja, das ist ein Nachteil, wenn man viel einstellen und viel verstellen kann. Man müsste sich vorher auskennen, um sagen zu können, was davon brauche ich eigentlich? Ein Editor mit Syntaxhighlighting und wenig Schnickschnack ist am Anfang am besten. Der in weniger als 1s startet, damit man Lust hat, ihn auch zu benutzen.
Die IDE kann viele Vorteile für einen Anfänger haben, zum Beispiel die automatische PEP-8-Formatierung.
Handformatierung ist nötig, falls man mit einem Problem nicht weiterkommt. Dann kann man die Einrückungen geradeziehen und findet die Problemlösung, weil man sich nicht mehr auf den falschen Verdacht fokussiert.
Viele moderne Sprachen haben sogenannte "Standard-Praktiken" entwickelt (PEP-8, Golang Formatierungs-Anforderungen usw.), und der Start mit einer IDE kann tatsächlich bei Dingen wie der richtigen Formatierung, Namenskonventionen und Projektstruktur helfen. Es gibt einem Anfänger mehr Zeit, die Sprache tatsächlich zu lernen, und nicht beim ersten Vorstellungsgespräch in Verlegenheit gebracht zu werden, wenn er "CamelCase"-Variablen verwendet, obwohl Python PEP-8 eindeutig die Verwendung von "underscore_notation" befiehlt.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
linux-nerd schrieb:
Viele moderne Sprachen haben sogenannte "Standard-Praktiken" entwickelt (PEP-8, Golang Formatierungs-Anforderungen usw.),
Sprachen selbst entwickeln nichts. Anwender tun es. Standardpraktiken, sogar ohne "Anführungszeichen" (:TM:), haben sich auch mit alten Sprachen entwickelt, das hat mit der Modernität einer Sprache nichts zu tun. Sprachen ohne ordentliche, statische Typisierung benötigen da häufig Konventionen, wo andere Sprachen dank des Compilers Garantien haben, als Notbehelf, das ist richtig.
und der Start mit einer IDE kann tatsächlich bei Dingen wie der richtigen Formatierung, Namenskonventionen und Projektstruktur helfen.
Bezweifle ich. Entweder man lernt es, und begreift es, oder lässt sich gängeln ohne zu begreifen.
Es gibt einem Anfänger mehr Zeit, die Sprache tatsächlich zu lernen,
Inwiefern?
und nicht beim ersten Vorstellungsgespräch in Verlegenheit gebracht zu werden, wenn er "CamelCase"-Variablen verwendet, obwohl Python PEP-8 eindeutig die Verwendung von "underscore_notation" befiehlt.
Einem Programmierer, den ich einstellen wollte, würde man sagen können "bei uns musst Du Unterstrichnotation benutzen" und er könnte sich von jetzt auf gleich an die Richtlinie halten. Würde er antworten "ja, sonst meckert die IDE dauernd rum" gäbe das einen mittelfetten Minuspunkt.
|
Neral
Anmeldungsdatum: 3. Oktober 2007
Beiträge: 229
|
user_unknown schrieb: Sprachen ohne ordentliche, statische Typisierung benötigen da häufig Konventionen, wo andere Sprachen dank des Compilers Garantien haben, als Notbehelf, das ist richtig.
Du meinst Sprachen wie Java, in denen die ganze Welt camelCase benutzt? Oder Haskell, wo die Sprache erfordert, dass Datentypen in PascalCase geschrieben sind? Oder Rust, wo es eine Compiler-Warnung gibt, wenn man camelCase benutzt? SCNR 😈
|