Hallo, ich bin noch blutiger Python Anfänger aber durch meinen Urspruch von PHP komm ich mit der Sprache eigentlich herrlich klar. Ich hätte da allerdings ein paar Fragen zu gewissen Konventionen in Python: Zum einen bin ich bei der Benennung der Module sehr verwundert. Ich hätte eigentlich erwartet, dass Module entweder komplett klein geschrieben werden sollten oder als CamelCase. Nun treffen mich aber selbst in der Standard Bibliothek beide Typen an und ich habe jetzt keinen Schimmer, nach welcher Konvention ich meine Module benennen soll. Gibt es diesbezüglich überhaupt eine Konvention? Zweitens wäre da der Modul import. Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum. In PHP wo ich her komme gibt es das zwar auch in der Art (es wird ein Alias auf Namensraum + Klasse gesetzt) aber das verwendet eigentlich Niemand, zumindest habe ich es noch nie gesehen. In Python habe ich den Einsatz davon bereits gesehen. Es wird zwar nach meinem ersten Eindruck sehr global importiert (oft nur das Basis Packet) aber teilweise werden auch wirklich einzelne Funktionen importiert. Jetzt würde mich natürlich interessieren, ob da ein System steckt. So nach dem Motto Funktionen wie time.time() (statisch + wahrscheinlich relativ einzigartig) importieren wir jetzt direkt während wir urllib.URLOpener nicht direkt importieren, sondern nur urllib, weil es noch andere URLOpener geben könnte, die man verwenden könnte irgendwo. Also was ich meine, macht das jeder frei Schnauze so wie ich das eben mal angedeutet habe wie ich denken würde, oder gibt es da von Sprachentwicklern und Community wirkliche Konventionen/Best Practice. Gruß Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.python.org/dev/peps/pep-0008/ Sebastian Bechtel wrote:
Hallo,
ich bin noch blutiger Python Anfänger aber durch meinen Urspruch von PHP komm ich mit der Sprache eigentlich herrlich klar.
Ich hätte da allerdings ein paar Fragen zu gewissen Konventionen in Python:
Zum einen bin ich bei der Benennung der Module sehr verwundert. Ich hätte eigentlich erwartet, dass Module entweder komplett klein geschrieben werden sollten oder als CamelCase. Nun treffen mich aber selbst in der Standard Bibliothek beide Typen an und ich habe jetzt keinen Schimmer, nach welcher Konvention ich meine Module benennen soll. Gibt es diesbezüglich überhaupt eine Konvention?
Zweitens wäre da der Modul import.
Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum.
In PHP wo ich her komme gibt es das zwar auch in der Art (es wird ein Alias auf Namensraum + Klasse gesetzt) aber das verwendet eigentlich Niemand, zumindest habe ich es noch nie gesehen.
In Python habe ich den Einsatz davon bereits gesehen. Es wird zwar nach meinem ersten Eindruck sehr global importiert (oft nur das Basis Packet) aber teilweise werden auch wirklich einzelne Funktionen importiert. Jetzt würde mich natürlich interessieren, ob da ein System steckt. So nach dem Motto Funktionen wie time.time() (statisch + wahrscheinlich relativ einzigartig) importieren wir jetzt direkt während wir urllib.URLOpener nicht direkt importieren, sondern nur urllib, weil es noch andere URLOpener geben könnte, die man verwenden könnte irgendwo.
Also was ich meine, macht das jeder frei Schnauze so wie ich das eben mal angedeutet habe wie ich denken würde, oder gibt es da von Sprachentwicklern und Community wirkliche Konventionen/Best Practice.
Gruß Sebastian
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
- -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 Tübingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxSxYMACgkQCJIWIbr9KYyRCQCglkF0F9IVyJV6M1ze1JTMeteM OlUAmQFxizLVNjI30XWEZGje5OHFxPUs =vh2K -----END PGP SIGNATURE-----
Hallo Sebastian, 2010/7/30 Sebastian Bechtel <me@sebastian-bechtel.info>:
Hallo,
ich bin noch blutiger Python Anfänger aber durch meinen Urspruch von PHP komm ich mit der Sprache eigentlich herrlich klar.
na dann: Willkommen! :)
Ich hätte da allerdings ein paar Fragen zu gewissen Konventionen in Python:
Zum einen bin ich bei der Benennung der Module sehr verwundert. Ich hätte eigentlich erwartet, dass Module entweder komplett klein geschrieben werden sollten oder als CamelCase. Nun treffen mich aber selbst in der Standard Bibliothek beide Typen an und ich habe jetzt keinen Schimmer, nach welcher Konvention ich meine Module benennen soll. Gibt es diesbezüglich überhaupt eine Konvention?
*Die* Referenz für Style-Konventionen in Python ist die PEP8: http://www.python.org/dev/peps/pep-0008/ Auch wenn natürlich jedes Projekt seine eigenen Konventionen hat, die in PEP8 dargestellten Style-Konventionen kann man im Zweifelsfall guten Gewissens zu Rate ziehen. Bei Fragen, die eher in Richtung Programmierrichtlinien (statt Style-Konventionen) gehen, kann ich den Python Style Guide von Google empfehlen: http://google-styleguide.googlecode.com/svn/trunk/pyguide.html Aber das ist eher eine persönl. Empfehlung. Die CamelCase-Module in der Standardbibliothek sind zumeist schon seehr lange unter diesen Namen in der Standard-Bibliothek. In Python 3.x wurden viele Namen vereinheitlich (siehe z.B. configparser: http://docs.python.org/py3k/library/configparser.html#module-configparser).
Zweitens wäre da der Modul import.
Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum.
In PHP wo ich her komme gibt es das zwar auch in der Art (es wird ein Alias auf Namensraum + Klasse gesetzt) aber das verwendet eigentlich Niemand, zumindest habe ich es noch nie gesehen.
In Python habe ich den Einsatz davon bereits gesehen. Es wird zwar nach meinem ersten Eindruck sehr global importiert (oft nur das Basis Packet) aber teilweise werden auch wirklich einzelne Funktionen importiert. Jetzt würde mich natürlich interessieren, ob da ein System steckt. So nach dem Motto Funktionen wie time.time() (statisch + wahrscheinlich relativ einzigartig) importieren wir jetzt direkt während wir urllib.URLOpener nicht direkt importieren, sondern nur urllib, weil es noch andere URLOpener geben könnte, die man verwenden könnte irgendwo.
Also was ich meine, macht das jeder frei Schnauze so wie ich das eben mal angedeutet habe wie ich denken würde, oder gibt es da von Sprachentwicklern und Community wirkliche Konventionen/Best Practice.
Gruß Sebastian
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Sebastian, Am Fri, 30 Jul 2010 13:49:09 +0200 schrieb Sebastian Bechtel <me@sebastian-bechtel.info>:
Zum einen bin ich bei der Benennung der Module sehr verwundert. Ich hätte eigentlich erwartet, dass Module entweder komplett klein geschrieben werden sollten oder als CamelCase. Nun treffen mich aber selbst in der Standard Bibliothek beide Typen an und ich habe jetzt keinen Schimmer, nach welcher Konvention ich meine Module benennen soll. Gibt es diesbezüglich überhaupt eine Konvention? Gibt es, wie bei vielem in Python in das in einem PEP (Python Enhancement Proposal) beschrieben, nämlich in PEP8 http://www.python.org/dev/peps/pep-0008/
Und da heisst es unter Package and Module Names: Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged. Nach welchen Regeln allerdings einige Module der Standardbibliothek nicht komplett klein geschrieben sind kann ich dir auch nicht sagen.
In Python habe ich den Einsatz davon bereits gesehen. Es wird zwar nach meinem ersten Eindruck sehr global importiert (oft nur das Basis Packet) aber teilweise werden auch wirklich einzelne Funktionen importiert. Jetzt würde mich natürlich interessieren, ob da ein System steckt. So nach dem Motto Funktionen wie time.time() (statisch + wahrscheinlich relativ einzigartig) importieren wir jetzt direkt während wir urllib.URLOpener nicht direkt importieren, sondern nur urllib, weil es noch andere URLOpener geben könnte, die man verwenden könnte irgendwo. Ich mache das eigentlich immer je nach Anwendungsfall. Wenn ich Funktionen aus os brauche importiere ich via "import os" das Modul, so kann man im Code gut sehen woher ein Symbol stammt. Prinzipiell ist allerdings alles möglich, nur verhindern sollte man "Stern-Imports", also z.B. "from os import *". So kann man im code gar nicht mehr sehen wo etwas herkommt. Pylint (http://pypi.python.org/pypi/pylint) bemängelt auch derartige Imports. ("W: 1: Wildcard import os")
Im PEP Index (http://www.python.org/dev/peps/) findet man auch einiges zu Imports im Besonderen. Viele Grüße Sven
Hi, danke Dir und natürlich auch den anderen beiden. Damit habe ich ja direkt meine gute Nacht Lektüre gefunden ;-) Gruß Sebastian Am 30.07.2010 um 16:55 schrieb Sven Broeckling:
Hallo Sebastian,
Am Fri, 30 Jul 2010 13:49:09 +0200 schrieb Sebastian Bechtel <me@sebastian-bechtel.info>:
Zum einen bin ich bei der Benennung der Module sehr verwundert. Ich hätte eigentlich erwartet, dass Module entweder komplett klein geschrieben werden sollten oder als CamelCase. Nun treffen mich aber selbst in der Standard Bibliothek beide Typen an und ich habe jetzt keinen Schimmer, nach welcher Konvention ich meine Module benennen soll. Gibt es diesbezüglich überhaupt eine Konvention? Gibt es, wie bei vielem in Python in das in einem PEP (Python Enhancement Proposal) beschrieben, nämlich in PEP8 http://www.python.org/dev/peps/pep-0008/
Und da heisst es unter Package and Module Names: Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.
Nach welchen Regeln allerdings einige Module der Standardbibliothek nicht komplett klein geschrieben sind kann ich dir auch nicht sagen.
In Python habe ich den Einsatz davon bereits gesehen. Es wird zwar nach meinem ersten Eindruck sehr global importiert (oft nur das Basis Packet) aber teilweise werden auch wirklich einzelne Funktionen importiert. Jetzt würde mich natürlich interessieren, ob da ein System steckt. So nach dem Motto Funktionen wie time.time() (statisch + wahrscheinlich relativ einzigartig) importieren wir jetzt direkt während wir urllib.URLOpener nicht direkt importieren, sondern nur urllib, weil es noch andere URLOpener geben könnte, die man verwenden könnte irgendwo. Ich mache das eigentlich immer je nach Anwendungsfall. Wenn ich Funktionen aus os brauche importiere ich via "import os" das Modul, so kann man im Code gut sehen woher ein Symbol stammt. Prinzipiell ist allerdings alles möglich, nur verhindern sollte man "Stern-Imports", also z.B. "from os import *". So kann man im code gar nicht mehr sehen wo etwas herkommt. Pylint (http://pypi.python.org/pypi/pylint) bemängelt auch derartige Imports. ("W: 1: Wildcard import os")
Im PEP Index (http://www.python.org/dev/peps/) findet man auch einiges zu Imports im Besonderen.
Viele Grüße Sven
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am 30.07.2010 13:49, schrieb Sebastian Bechtel:
Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum.
Meines Erachtens gehört diese Möglichkeit zu den größten Design-Schwächen von Python (was nur beweist, dass Python schon ziemlich perfekt ist, wenn mir nichts schlimmeres daran auffällt). Wenn ich mich präzise ausdrücken kann, warum sollte ich es dann nicht tun? Schreibe ich nur time() in meinen Code, wird vermutlich noch jedem Leser klar sein, um was es geht. Wer es nicht weiß, muss dann schon nach oben in die import-Liste scrollen und nachsehen. Nun könnte man argumentieren, dass das zumutbar sei - aber welcher Gewinn steht dem gegenüber? Dass man ab der dritten Verwendung einige Bytes spart? Hey, wir machen doch kein Perl hier. Namensräume können auch für Programmierer ein nützliches Hilfsmittel sein, denn sie helfen nicht nur dem Interpreter beim gedanklichen Einordnen von Objekten. Ich sehe also keinen Grund, sich selbst (also dem Programmierer, der in einem halben Jahr auf den Code schaut, als sähe er ihn zum ersten Mal) diese Hilfe zu nehmen. Und die Treffsicherheit hast Du ja auch schon angesprochen: Auch, wenn man davon ausgehen kann, dass time() wohl von nirgendwo sonst kommen wird - sicher ist das keinesfalls. Irgendwann wird sich jemand finden, der in Deinem Modul eine lokale time-Funktion einbaut. Sein Code, der die benutzt, wird dann auch funktionieren. Deiner aber nicht mehr. Oder, schlimmer noch, er wird sich nur anders verhalten, und Du wirst es erst bemerken, wenn der Kunde drüber meckert. :-) Vom Zusatzaufwand beim Refaktorieren will ich jetzt mal gar nicht erst anfangen - ich komme mir ja schon ganz destruktiv vor. Also gut, ein Vorteil des "from ... import ..." fällt mir dann doch ein: Bei sehr großen Modulen verringert das den Overhead, weil nur das im Speicher lagert, was auch gebraucht wird. Wenn allerdings ein Modul wirklich derart groß ist, dass sich das bemerkbar macht, ist vermutlich auch schon irgendetwas aus dem Ruder gelaufen... So, genug der Meinungsäußerung. Wirkliche Fakten und Links haben ja andere schon geliefert. -- [x] u1f
Am 30.07.2010 23:03, schrieb Ulf Rompe:
Am 30.07.2010 13:49, schrieb Sebastian Bechtel:
Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum.
Meines Erachtens gehört diese Möglichkeit zu den größten Design-Schwächen von Python (was nur beweist, dass Python schon ziemlich perfekt ist, wenn mir nichts schlimmeres daran auffällt). Wenn ich mich präzise ausdrücken kann, warum sollte ich es dann nicht tun? Schreibe ich nur time() in meinen Code, wird vermutlich noch jedem Leser klar sein, um was es geht. Wer es nicht weiß, muss dann schon nach oben in die import-Liste scrollen und nachsehen. Nun könnte man argumentieren, dass das zumutbar sei - aber welcher Gewinn steht dem gegenüber? Dass man ab der dritten Verwendung einige Bytes spart? Hey, wir machen doch kein Perl hier.
Es ist aber halt schon etwas mühselig, jedesmal "django.forms.extras.widgets.SelectDateWidget" zu schreiben (das ist jetzt eine zufällig ausgewählte Klasse aus Django). Da bietet der from-Import einfach Komfort, und wie du schon bemerkt hast, immerhin steht oben in der Datei, wo der Name herkommt. Schlimmer IMO ist das in anderen Sprachen, z.B. in Haskell, wo ein "import Foo" automatisch alle Funktionen aus "Foo" zur Verfügung stellt, ohne dass irgendwo stehen muss, welche das sind. Für Pakethierarchien gibts ja auch die Möglichkeit des "abgestuften" from-Imports, also z.B. from django.forms.extras import widgets und dann widgets.SelectDateWidget was einen recht guten Kompromiss darstellt.
Und die Treffsicherheit hast Du ja auch schon angesprochen: Auch, wenn man davon ausgehen kann, dass time() wohl von nirgendwo sonst kommen wird - sicher ist das keinesfalls. Irgendwann wird sich jemand finden, der in Deinem Modul eine lokale time-Funktion einbaut. Sein Code, der die benutzt, wird dann auch funktionieren. Deiner aber nicht mehr. Oder, schlimmer noch, er wird sich nur anders verhalten, und Du wirst es erst bemerken, wenn der Kunde drüber meckert. :-)
Ja, da tun Tools wie pyflakes gut, die auch sonst beim Entwickeln nicht fehlen sollten.
Vom Zusatzaufwand beim Refaktorieren will ich jetzt mal gar nicht erst anfangen - ich komme mir ja schon ganz destruktiv vor.
Also gut, ein Vorteil des "from ... import ..." fällt mir dann doch ein: Bei sehr großen Modulen verringert das den Overhead, weil nur das im Speicher lagert, was auch gebraucht wird. Wenn allerdings ein Modul wirklich derart groß ist, dass sich das bemerkbar macht, ist vermutlich auch schon irgendetwas aus dem Ruder gelaufen...
Das ist allerdings eine Fehleinschätzung; egal ob "import foo" oder "from foo import X", in beiden Fällen wird das Modul geladen, und zwar komplett -- anders funktioniert das auch nicht. Der Unterschied besteht nur darin, welche Namen im Namensraum des Importeurs gebunden werden. cheers, Georg
Am 31.07.2010 01:21, schrieb Georg Brandl:
Ja, da tun Tools wie pyflakes gut, die auch sonst beim Entwickeln nicht fehlen sollten.
Da stimme ich zu. pylint läuft hier quasi dauernd, pyflakes und pychecker einmal vor jedem commit.
Also gut, ein Vorteil des "from ... import ..." fällt mir dann doch ein: Bei sehr großen Modulen verringert das den Overhead, weil nur das im Speicher lagert, was auch gebraucht wird. Wenn allerdings ein Modul wirklich derart groß ist, dass sich das bemerkbar macht, ist vermutlich auch schon irgendetwas aus dem Ruder gelaufen... Das ist allerdings eine Fehleinschätzung; egal ob "import foo" oder "from foo import X", in beiden Fällen wird das Modul geladen, und zwar komplett -- anders funktioniert das auch nicht.
Das war mir tatsächlich nicht bewusst. Dass die Module erst einmal komplett geladen werden müssen, ist ja klar, aber anschließend... Ja, jetzt, wo ich noch einmal darüber nachdenke, wird mir auch klar, dass das nicht klappen kann. -- [x] u1f
Ulf Rompe <python-de@rompe.org> writes:
Am 30.07.2010 13:49, schrieb Sebastian Bechtel:
Es ist ja Möglich, mit from ... import ... sehr spezifisch Dinge zu importieren in den Namenraum.
Meines Erachtens gehört diese Möglichkeit zu den größten Design-Schwächen von Python (was nur beweist, dass Python schon ziemlich perfekt ist, wenn mir nichts schlimmeres daran auffällt). Wenn ich mich präzise ausdrücken kann, warum sollte ich es dann nicht tun?
Mit from ... import ... kann ich präzise ausdrücken, *was* ich importieren will. Das kann manchmal sinnvoll sein, z.B. wenn ich aus einem großen Modul nur einige wenige Namen importieren will.
Schreibe ich nur time() in meinen Code, wird vermutlich noch jedem Leser klar sein, um was es geht.
time() finde ich da ein eher schlechtes Beispiel, es gibt vermutlich eine ganze Menge Module, die eine Funktion time() implementieren. Ein typisches Beispiel, wo from ... import .. verwende, ist z.B. ein Modul "config", das einen dict "config" mit Konfigurationseinstellungen enthält. Da ständig config.config['foo'] statt config['foo'] zu schreiben, macht den Code IMHO nicht übersichtlicher, sondern nur länger (solange ich den Namen "config" konsequent nur für dieses Objekt benutze).
Nun könnte man argumentieren, dass das zumutbar sei - aber welcher Gewinn steht dem gegenüber? Dass man ab der dritten Verwendung einige Bytes spart?
Die jedesmal explizit angegebenen Modulnamen können dazu führen, dass Zeilen oder Ausdrücke sehr lang werden oder ungünstig umbrochen werden müssen. Dadurch kann der Code evtl. unübersichtlicher werden. Florian -- <http://www.florian-diesch.de/linux/asciipinguine.html>
Am 31.07.2010 18:42, schrieb Florian Diesch:
Mit from ... import ... kann ich präzise ausdrücken,*was* ich importieren will.
Das ist wahr. Aber dafür drückst Du anschließend im Code nicht mehr präzise aus, was Du verwenden willst. Die große Gefahr bei der unpräzisen Ausdrucksweise sehe ich auch gar nicht bei der initialen Entwicklung. Nun ist es aber so, dass die meisten Quellcodes leben, sich also immer wieder etwas verändern, ab und zu einmal umziehen, und manchmal auch an ganz anderer Stelle wiederverwendet werden. Und wenn dann ein Block nicht von einem genau dafür geschnitzten import-Statement sowie der Abwesenheit gleichlautender Namen im neuen Kontext abhängt, finde ich das sehr beruhigend. -- [x] u1f
Ulf Rompe <python-de@rompe.org> writes:
Am 31.07.2010 18:42, schrieb Florian Diesch:
Mit from ... import ... kann ich präzise ausdrücken,*was* ich importieren will.
Das ist wahr. Aber dafür drückst Du anschließend im Code nicht mehr präzise aus, was Du verwenden willst.
Die große Gefahr bei der unpräzisen Ausdrucksweise sehe ich auch gar nicht bei der initialen Entwicklung. Nun ist es aber so, dass die meisten Quellcodes leben, sich also immer wieder etwas verändern, ab und zu einmal umziehen, und manchmal auch an ganz anderer Stelle wiederverwendet werden. Und wenn dann ein Block nicht von einem genau dafür geschnitzten import-Statement sowie der Abwesenheit gleichlautender Namen im neuen Kontext abhängt, finde ich das sehr beruhigend.
Da ist es andererseits aber auch beruhigend, wenn Python sich sofort beschwert, wenn nicht alles importiert werden kann, was für das Programm benötigt wird. Ich sehe bei beiden Möglichkeiten Vor- und Nachteile und entscheide daher fallweise, was jeweils die beste Lösung ist. Florian -- <http://www.florian-diesch.de/doc/emacs/>
participants (7)
-
Andi Albrecht -
Andreas Jung -
Florian Diesch -
Georg Brandl -
Sebastian Bechtel -
Sven Broeckling -
Ulf Rompe