Konventionen

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Konventionen

Sebastian Bechtel
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  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Andreas Jung-5
-----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  -  [hidden email]
> 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-----

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de

lists.vcf (331 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Andi Albrecht-2
In reply to this post by Sebastian Bechtel
Hallo Sebastian,

2010/7/30 Sebastian Bechtel <[hidden email]>:
> 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  -  [hidden email]
> http://python.net/mailman/listinfo/python-de
>

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Sven Bröckling
In reply to this post by Sebastian Bechtel
Hallo Sebastian,

Am Fri, 30 Jul 2010 13:49:09 +0200
schrieb Sebastian Bechtel <[hidden email]>:

> 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  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Sebastian Bechtel
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 <[hidden email]>:
>
>> 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  -  [hidden email]
> http://python.net/mailman/listinfo/python-de


_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Ulf Rompe-5
In reply to this post by Sebastian Bechtel
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

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Georg Brandl-2
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


_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Florian Diesch
In reply to this post by Ulf Rompe-5
Ulf Rompe <[hidden email]> 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>

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Ulf Rompe-5
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

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Florian Diesch
Ulf Rompe <[hidden email]> 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/>

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de
Reply | Threaded
Open this post in threaded view
|

Re: Konventionen

Ulf Rompe-5
In reply to this post by Georg Brandl-2
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

_______________________________________________
python-de maillist  -  [hidden email]
http://python.net/mailman/listinfo/python-de