Anfängerfrage: welche Parameter hat eine Funktion/Methode?
michael bode
ich versuche gerade meine ersten Schritte mit Python und bin auf
folgendes Problem gestoï¿œen: C hat seine Header Files, Ada hat Package
Specifications in denen Funktionsprototypen oder sowas ï¿œhnliches stehen,
aus denen auch der Programmierer rausfinden kann, welche Funktionen
ein Modul/Package/was-noch hat und welche Parameter von welchem Typ die
erwarten. Wie kriege ich das bei einem fremden Python Modul raus, wenn
ich keine Doku dazu hab?
Konkreter Fall ist gnomekeyring. Grob kann man sich da an der C-Doku
orientieren, aber ich bin bisher nicht dahinter gekommen, wie ich an die
genauen Angaben zum Python-Binding komme. Noch wie das Python-Binding
ï¿œberhaupt funktioniert. Sowas wie eine gnomekeyring.py finde ich nicht.
Thomas Rachel
> Hi,
>
> ich versuche gerade meine ersten Schritte mit Python und bin auf
> Specifications in denen Funktionsprototypen oder sowas ähnliches stehen,
> Modul/Package/was-noch hat und welche Parameter von welchem Typ die
> erwarten. Wie kriege ich das bei einem fremden Python Modul raus, wenn
> ich keine Doku dazu hab?
Das kommt darauf an, wie das Modul geschrieben ist. Ist es ein Modul in
Python (.py,.pyc,.pyo), kannst Du die Hilfe zu Rate ziehen:
help(<modul>) oder help(<modul>.<funktion>). Die zeigt Dir auch, wenn
der Modulersteller keinen docstring hinterlegt hat, zumindest die Anzahl
der Parameter sowie ggf. deren Defaults.
Hast Du hingegen ein C-Modul (.dll, .so), bleibt Dir eigentlich nur die
Hoffnung, daß der Programmierer gescheite docstrings definiert hat oder
sonstwo eine Dokumentation zu finden ist. Ist dies auch nicht der Fall,
bleibt nur der Blick in den Quellcode oder in anderen Code, der das
Modul verwendet.
> Konkreter Fall ist gnomekeyring. Grob kann man sich da an der C-Doku
> orientieren, aber ich bin bisher nicht dahinter gekommen, wie ich an die
> genauen Angaben zum Python-Binding komme. Noch wie das Python-Binding
> überhaupt funktioniert. Sowas wie eine gnomekeyring.py finde ich nicht.
Die ist dann wohl ein Fall von Punkt 2 oben...
Debian? Falls ja, lautet die Dateiliste des Paketes so:
/usr/lib/pyshared/python2.5/gtk-2.0/gnomekeyring.so
/usr/share/doc/python-gnomekeyring/changelog.Debian.gz
/usr/share/doc/python-gnomekeyring/changelog.gz
/usr/share/doc/python-gnomekeyring/copyright
/usr/share/doc/python-gnomekeyring/examples/keyring-async.py
/usr/share/doc/python-gnomekeyring/examples/keyring.py
/usr/share/python-support/python-gnomekeyring.public
Was steht denn in den Examples da? (Hab kein Debian; habs nur über
google gefunden)
Grundsätzlich könnte ein
import gnomekeyring
gefolgt von einem
help(gnomekeyring)
evtl. das eine oder andere zu Tage fördern.
Ansonsten wäre
http://library.gnome.org/misc/release-notes/2.14/index.html.de Deine
Anlaufstelle.
Wirst Du da auch nicht fündig, wäre das Quellpaket
(http://packages.debian.org/de/source/sid/gnome-python-desktop)
relevant. Da hülfe dann nur auspacken und nachschauen, wie der C-Teil
aufgebaut ist.
Thomas
michael bode
> Das kommt darauf an, wie das Modul geschrieben ist. Ist es ein Modul in
> Python (.py,.pyc,.pyo), kannst Du die Hilfe zu Rate ziehen:
> help(<modul>) oder help(<modul>.<funktion>). Die zeigt Dir auch, wenn
> der Modulersteller keinen docstring hinterlegt hat, zumindest die Anzahl
> der Parameter sowie ggf. deren Defaults.
>
> Hast Du hingegen ein C-Modul (.dll, .so), bleibt Dir eigentlich nur die
> Hoffnung, daß der Programmierer gescheite docstrings definiert hat oder
> sonstwo eine Dokumentation zu finden ist. Ist dies auch nicht der Fall,
> bleibt nur der Blick in den Quellcode oder in anderen Code, der das
> Modul verwendet.
Hm, irgendwie muss der Python Interpreter doch auch an die Information
kommen. Speziell da Python ja named parameters hat, müssen ja sogar die
Namen der Parameter vorhanden sein. Ich hatte gehofft, dass man ähnlich
wie bei Java .class Files diese Information irgendwie aus der .so
auslesen kann. (Zumindest zeigt mir Netbeans bei .class Files die
Methoden und Parameter auch ohne Javadoc Kommentare an)
> Die ist dann wohl ein Fall von Punkt 2 oben...
>
> Debian? Falls ja, lautet die Dateiliste des Paketes so:
Jepp.
> Was steht denn in den Examples da? (Hab kein Debian; habs nur über
> google gefunden)
Das Keyring Example verwendet ein paar Funktionen aber nicht alle. Ich
hab einigermaßen rausfinden können, was ich brauche, aber ich dachte
halt da muss es auch eine reguläre Methode geben, da ja wie gesagt der
Interpreter die Informationen auch haben muss.
> Wirst Du da auch nicht fündig, wäre das Quellpaket
> (http://packages.debian.org/de/source/sid/gnome-python-desktop)
> relevant. Da hülfe dann nur auspacken und nachschauen, wie der C-Teil
> aufgebaut ist.
Ist in den Fall nicht so ohne, weil das über verschiedene
Codegeneratoren aus den C Headern erzeugt wird. Offenbar wird erstmal
eine Lisp-artige Beschreibung der C-Funktionen erzeugt (.defs), die per
.override Dateien modifiziert wird und dann in einen C Codegenerator
gefüttert wird.
Georg Brandl
> Thomas Rachel schrieb:
>
>> Das kommt darauf an, wie das Modul geschrieben ist. Ist es ein Modul in
>> Python (.py,.pyc,.pyo), kannst Du die Hilfe zu Rate ziehen:
>> help(<modul>) oder help(<modul>.<funktion>). Die zeigt Dir auch, wenn
>> der Modulersteller keinen docstring hinterlegt hat, zumindest die Anzahl
>> der Parameter sowie ggf. deren Defaults.
>>
>> Hast Du hingegen ein C-Modul (.dll, .so), bleibt Dir eigentlich nur die
>> Hoffnung, daß der Programmierer gescheite docstrings definiert hat oder
>> sonstwo eine Dokumentation zu finden ist. Ist dies auch nicht der Fall,
>> bleibt nur der Blick in den Quellcode oder in anderen Code, der das
>> Modul verwendet.
>
> Hm, irgendwie muss der Python Interpreter doch auch an die Information
> kommen. Speziell da Python ja named parameters hat, müssen ja sogar die
> Namen der Parameter vorhanden sein. Ich hatte gehofft, dass man ähnlich
> wie bei Java .class Files diese Information irgendwie aus der .so
> auslesen kann. (Zumindest zeigt mir Netbeans bei .class Files die
> Methoden und Parameter auch ohne Javadoc Kommentare an)
Nein, das kann man für C-Funktionen nicht. Python C-Extensions sind reine
C shared libraries, die haben keine Metainformationen über Signaturen.
Nichtmal die Signatur der C-Funktion würde dir was nützen: C-Funktionen,
die aus Python aufrufbar sein sollen, bekommen lediglich einen Pointer
zu einem Tupel (entsprechend *args) und optional einem Dict (entsprechend
**kwds). Zerpflückt in einzelne Argumente wird das dann durch einen
Aufruf von PyArg_ParseTuple[AndKeywords] innerhalb der Funktion.
Das einzige, was dir also helfen könnte, ist der C-Quellcode, oder wenn
der aus Headern generiert wird, die Header plus ein paar Informationen,
welche Python-Typen auf welche C-Typen gemappt werden.
BTW: Viele C-Extensions unterstützen gar keine "named parameters" ("keyword
arguments" in Python-Terminologie).
Georg
Diez B. Roggisch
> Thomas Rachel schrieb:
>
>> Das kommt darauf an, wie das Modul geschrieben ist. Ist es ein Modul
>> in Python (.py,.pyc,.pyo), kannst Du die Hilfe zu Rate ziehen:
>> help(<modul>) oder help(<modul>.<funktion>). Die zeigt Dir auch, wenn
>> der Modulersteller keinen docstring hinterlegt hat, zumindest die
>> Anzahl der Parameter sowie ggf. deren Defaults.
>>
>> Hast Du hingegen ein C-Modul (.dll, .so), bleibt Dir eigentlich nur
>> die Hoffnung, daß der Programmierer gescheite docstrings definiert hat
>> oder sonstwo eine Dokumentation zu finden ist. Ist dies auch nicht der
>> Fall, bleibt nur der Blick in den Quellcode oder in anderen Code, der
>> das Modul verwendet.
>
> Hm, irgendwie muss der Python Interpreter doch auch an die Information
> kommen. Speziell da Python ja named parameters hat, müssen ja sogar die
> Namen der Parameter vorhanden sein. Ich hatte gehofft, dass man ähnlich
> wie bei Java .class Files diese Information irgendwie aus der .so
> auslesen kann. (Zumindest zeigt mir Netbeans bei .class Files die
> Methoden und Parameter auch ohne Javadoc Kommentare an)
Das ist ja auch kein Wunder - Java ist statisch typisiert, aber
gleichzeitig erlaubt es Reflektion ueber Methoden. Damit kann man einer
Klasse die Signaturen all ihrer Methoden entnehmen.
Python kann das aber nicht - weil es nicht statisch typisiert ist.
Diez
Thomas Rachel
> Hm, irgendwie muss der Python Interpreter doch auch an die Information
> kommen.
_.replace("thon Inter","thon-Inter")
Nö. Python ruft einfach auf und übergibt die Parameter. Die Auswertung
erfolgt ähnlich wie bei einer Funktion, die mit den Parametern (*a,**k)
deklariert wurde: einach alles reinstecken. Die Funktion muß dann selbst
auswerten.
> Speziell da Python ja named parameters hat, müssen ja sogar die
> Namen der Parameter vorhanden sein. Ich hatte gehofft, dass man ähnlich
> wie bei Java .class Files diese Information irgendwie aus der .so
> auslesen kann. (Zumindest zeigt mir Netbeans bei .class Files die
> Methoden und Parameter auch ohne Javadoc Kommentare an)
Bei Python-Modulen geht das ja auch, weil die entsprechenden
Informationen (außer Typ - Python ist eben nicht typisiert) auch im
Funktionsobjekt drinstehen:
>>> def f(a,b,c,d=9, e=12): pass
>>> f.func_defaults
(9, 12)
>>> f.func_code.co_argcount
5
>>> f.func_code.co_varnames
('a', 'b', 'c', 'd', 'e')
>>> f.func_code.co_flags # da steckt auch noch für help() nützliche
Information drin... gibt es *a? gibt es **k? ist es ein Generator? etc.
67
>>> help(f)
> Das Keyring Example verwendet ein paar Funktionen aber nicht alle. Ich
> hab einigermaßen rausfinden können, was ich brauche, aber ich dachte
> halt da muss es auch eine reguläre Methode geben, da ja wie gesagt der
> Interpreter die Informationen auch haben muss.
Wie gesagt, der übergibt alles was er hat, der Funktion und überläßt die
dann ihrem Schicksal.
> Ist in den Fall nicht so ohne, weil das über verschiedene
> Codegeneratoren aus den C Headern erzeugt wird. Offenbar wird erstmal
> eine Lisp-artige Beschreibung der C-Funktionen erzeugt (.defs), die per
> ..override Dateien modifiziert wird und dann in einen C Codegenerator
> gefüttert wird.
igitt... dann viel Spaß...
Thomas
michael bode
> Nein, das kann man für C-Funktionen nicht. Python C-Extensions sind reine
> C shared libraries, die haben keine Metainformationen über Signaturen.
>
> Nichtmal die Signatur der C-Funktion würde dir was nützen: C-Funktionen,
> die aus Python aufrufbar sein sollen, bekommen lediglich einen Pointer
> zu einem Tupel (entsprechend *args) und optional einem Dict (entsprechend
> **kwds). Zerpflückt in einzelne Argumente wird das dann durch einen
> Aufruf von PyArg_ParseTuple[AndKeywords] innerhalb der Funktion.
Ach so machen die das. Ich hatte in "Python" von Peter Kaiser, Johannes
Ernesti gelesen, die Standardmethode für Bindings an C-Code wäre sowas wie:
import ctypes
bibliothek = ctypes.CDLL("MSVCRT")
bibliothek.printf("Hallo Welt\n")
ggf. mit ein bischen Wrapper-Code drumrum, um das ganze Python-like zu
machen (Strings etc.)
Das ist ziemlich ähnlich zu dem, was man in Ada (meine derzeitige
Hauptsprache) machen würde. Fand ich interessant, weil Ada in etlichen
Aspekten so ziemlich das Gegenteil von Python ist.
Marek Kubica
michael bode <m.g....@web.de> wrote:
> > Nichtmal die Signatur der C-Funktion würde dir was nützen:
> > C-Funktionen, die aus Python aufrufbar sein sollen, bekommen
> > lediglich einen Pointer zu einem Tupel (entsprechend *args) und
> > optional einem Dict (entsprechend **kwds). Zerpflückt in einzelne
> > Argumente wird das dann durch einen Aufruf von
> > PyArg_ParseTuple[AndKeywords] innerhalb der Funktion.
>
> Ach so machen die das. Ich hatte in "Python" von Peter Kaiser,
> Johannes Ernesti gelesen, die Standardmethode für Bindings an C-Code
> wäre sowas wie:
>
> import ctypes
> bibliothek = ctypes.CDLL("MSVCRT")
> bibliothek.printf("Hallo Welt\n")
>
> ggf. mit ein bischen Wrapper-Code drumrum, um das ganze Python-like
> zu machen (Strings etc.)
Nein. Also abgesehen davon dass das Buch eine mittlere Katastrophe
ist, sind ctypes-Bindings eher selten. Spontan fällt mir da nur pg8000
und PyOpenGL ein, die meisten Libraries nutzen hingegen SWIG, Cython
oder ähnliche Tools (oder nutzen die C API direkt).
Nicht das ctypes schlecht wäre, FFI über dlopen()/libffi ist relativ
verbreitet: Ruby nutzt das, Scheme nutzt das, Factor ebenfalls und
eigentlich hat jede Mainstream-Sprache eine FFI-Implementation. Nur ist
das bei Python-Extensions nicht die "Standardmethode".
> Das ist ziemlich ähnlich zu dem, was man in Ada (meine derzeitige
> Hauptsprache) machen würde. Fand ich interessant, weil Ada in
> etlichen Aspekten so ziemlich das Gegenteil von Python ist.
FFI ist überall ziemlich ähnlich.
grüße,
Marek
Thomas Mlynarczyk
["Python" von Peter Kaiser, Johannes Ernesti]
> Also abgesehen davon dass das Buch eine mittlere Katastrophe ist
Könntest Du das bitte begründen und ein wirklich gutes Python-Buch
empfehlen?
Gruß,
Thomas, der das Buch als Einstieg eigentlich nicht schlecht fand.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
Marek Kubica
Thomas Mlynarczyk <tho...@mlynarczyk-webdesign.de> wrote:
> Marek Kubica schrieb:
> ["Python" von Peter Kaiser, Johannes Ernesti]
> > Also abgesehen davon dass das Buch eine mittlere Katastrophe ist
>
> Könntest Du das bitte begründen und ein wirklich gutes Python-Buch
> empfehlen?
Aber logisch. Ich verweise dazu aber lieber auf existierende
Artikel/Threads, weil das schon zuhauf diskutiert wurde:
<http://bj.spline.de/python_openbook.html>
<http://www.python-forum.de/topic-12942.html>
<http://www.python-forum.de/topic-13008.html>
In den Diskussionsthreads stehen auch Empfehlungen zu anderen Büchern
drin, inzwischen ist aber übrigens auch Dive Into Python 3
erschienen <http://diveintopython3.org/> und die deutsche Übersetzung
des Python Tutorials (Version 3.1) <http://tutorial.pocoo.org/>.
grüße,
Marek
Thomas Mlynarczyk
> <http://bj.spline.de/python_openbook.html>
> <http://www.python-forum.de/topic-12942.html>
> <http://www.python-forum.de/topic-13008.html>
Danke! Besonders der erste Link war sehr aufschlußreich. Irgendwie fehlt
mir wohl noch ein ganzes Stück zur pythonischen Sichtweise -- gibt es da
nicht irgendeinen Artikel, der das Thema detailliert beleuchet?
<http://dirtsimple.org/2004/12/python-is-not-java.html> ist schonmal
gut, aber ich hätte das gerne ausführlicher und "philosophischer", mit
Codebeispielen.
> In den Diskussionsthreads stehen auch Empfehlungen zu anderen Büchern
> drin, inzwischen ist aber übrigens auch Dive Into Python 3
> erschienen <http://diveintopython3.org/> und die deutsche Übersetzung
> des Python Tutorials (Version 3.1) <http://tutorial.pocoo.org/>.
Da werde ich bei Gelegenheit mal gründlich drin schmökern.
Gruß und Dank,
Thomas