Angenommen, wir haben eine komplexe API-Funktion, die aus einer Bibliothek importiert wurde.
def complex_api_function(
number, <lots of positional arguments>,
<lots of keyword arguments>):
'''really long docstring'''
# lots of code
Ich möchte einen einfachen Wrapper um diese Funktion schreiben, um eine winzige Änderung vorzunehmen. Beispielsweise sollte es möglich sein, das erste Argument als Zeichenfolge zu übergeben. Wie kann man das dokumentieren? Ich habe folgende Optionen in Betracht gezogen:
Option 1:
def my_complex_api_function(number_or_str, *args, **kwargs):
'''
Do something complex.
Like `complex_api_function`, but first argument can be a string.
Parameters
----------
number_or_str : int or float or str
Can be a number or a string that can be interpreted as a float.
<copy paste description from complex_api_function docstring>
*args
Positional arguments passed to `complex_api_function`.
**kwargs
Keyword arguments passed to `complex_api_function`.
Returns
-------
<copy paste from complex_api_function docstring>
Examples
--------
<example where first argument is a string, e.g. '-5.0'>
'''
return complex_api_function(float(number_or_str), *args, **kwargs)
Nachteil: Der Benutzer muss sich die Dokumente von ansehen complex_api_function
, um Informationen über *args
und zu erhalten **kwargs
. Muss angepasst werden, wenn beim Kopieren Abschnitte aus der complex_api_function
Änderung eingefügt werden .
Option 2:
Kopieren Sie die complex_api_function
Signatur (anstelle von *args
und **kwargs
) und deren Dokumentzeichenfolge und fügen Sie sie ein. Nehmen Sie eine kleine Änderung an der Dokumentzeichenfolge vor, in der erwähnt wird, dass das erste Argument auch eine Zeichenfolge sein kann. Fügen Sie ein Beispiel hinzu.
Nachteil: ausführlich, muss bei complex_api_function
Änderungen geändert werden .
Option 3:
Dekorieren Sie my_complex_api_function
mit functools.wraps(complex_api_function)
.
Nachteil: Es gibt keine Informationen, number
die auch eine Zeichenfolge sein können.
Ich suche nach einer Antwort, die nicht von den Details abhängt, was sich ändert my_complex_api_function
. Das Verfahren sollte für jede winzige Anpassung an das Original funktionieren complex_api_function
.
quelle
complex_api_function
für seinen Parameter erwartet, da dies nur Informationen dupliziert (möglicherweise haben sie auch mehrere Optionen). Vermutlich ist der Benutzer des Wrappers bereits mit der ursprünglichen Funktion vertraut, und wenn nicht, können Sie sie immer auf die Originaldokumente verweisen. Wie auch immer, ich denke, dies ist der richtige Weg. Dokumentieren Sie nur, was der ursprünglichen Funktion hinzugefügt wurde , und geben Sie Details darüber an, wie dieser neue Typ in den ursprünglichen Typ konvertiert wird (diese Details könnten wichtig sein). Dh wie dieses Argument behandelt wird, um mit der ursprünglichen Funktion kompatibel zu sein.:ref:
in der Dokumentzeichenfolge hinzugefügt. Bei kleinen API-Änderungen, nach denen das OP fragt, können Benutzer die Funktionen jedoch einfacher vergleichen. In diesem Fall kann der minimale Aufwand den Endbenutzern ein wenig mehr Gewinn bringen - und wenn ich Dokumente lese, würde ich in den meisten Fällen ein 12-seitiges Dokument über ein 6-seitiges Dokument ziehen, da es so wenig einfacher zu verstehen ist.Sie können die "Spezialisierung" der Originaldokumentation mit einem Nachtrag automatisieren . Zum Beispiel pydoc wird mit der besonderen Eigenschaft
__doc__
. Sie könnten einen Dekorateur schreiben, der die ursprüngliche Funktion__doc__
mit Ihrem Nachtrag automatisch überschreibt .Zum Beispiel:
oder...
Wenn Sie pydoc (
pydoc3 -w my_module.py
) ausführen, wird Folgendes angezeigt : Vorschau des von pydoc generierten HTML-CodesZusätzlicher Hinweis: Wenn Sie Python 3 verwenden, können Sie Anmerkungen verwenden , um die Art (en) Ihrer Funktionsparameter zu dokumentieren. Es bietet viele Vorteile, nicht nur die Dokumentation. Zum Beispiel:
quelle
a : float
ganz oben angezeigt und kommt nie zu dem Schluss, dass er möglicherweise auch einestr
hier verwendet. Nur wenn sie zufällig bis zum Ende der Dokumente scrollen, werden sie es entdecken.complex_package >= 1.1.0
. Wenn Sie jetzt Ihr Paket erstellen, müssen Sie eine bestimmte Version für verwendencomplex_package
. Nehmen wir an, es gibt bereitscomplex_package==1.5.0
Pypi und sie habencomplex_api_function
in der Version ein neues Schlüsselwortargument hinzugefügt1.3.0
. In beiden Fällen (mit1.1.0
oder1.5.0
) haben Sie veraltete / falsche Informationen für eine Untergruppe Ihrer Benutzer im Dokument. Gleiches gilt für zukünftige Änderungen, die noch nicht öffentlich sind.Ich bin mir nicht sicher, ob dies das ist, wonach Sie suchen, aber es hilft, die Frage vollständig zu vermeiden.
quelle
wrapped_api_func
hat keine Dokumentzeichenfolge, daher ist das Dokumentationsproblem nicht gelöst.