Jak przedłużyć moduł python? (python-twitter)

Question

Jakie są najlepsze praktyki dotyczące rozbudowy modułu Pythona - w tym przypadku chcę rozszerzyć python-twitter przez dodanie nowych metod do podstawowej klasy API.

Spojrzałem na tweepy, a ja też to lubię, po prostu uważam, że python-twitter jest łatwiejszy do zrozumienia i poszerzenia o pożądaną funkcjonalność.

Mam już napisane metody, staram się wymyślić najlepszy sposób dodania ich do modułu, bez zmiany rdzenia.

Answer 1

Kilka sposobów.

Prosty sposób:

Nie przedłużyć moduł przedłużyć klas.

exttwitter.py

import twitter 

class Api(twitter.Api): 
    pass 
    # override/add any functions here. 

Wada: Każda klasa w Twitterze musi być exttwitter.py, nawet jeśli to tylko zalążek (jak wyżej)

trudniejsze (ewentualnie un-pythonic) sposób:

Importuj * z Pythona-twittera do modułu, który następnie rozszerzasz.

Na przykład:

basemodule.py

class Ball(): 
    def __init__(self,a): 
     self.a=a 
    def __repr__(self): 
     return "Ball(%s)" % self.a 

def makeBall(a): 
    return Ball(a) 

def override(): 
    print "OVERRIDE ONE" 

def dontoverride(): 
    print "THIS WILL BE PRESERVED" 

extmodule.py

from basemodule import * 
import basemodule 

def makeBalls(a,b): 
    foo = makeBall(a) 
    bar = makeBall(b) 
    print foo,bar 

def override(): 
    print "OVERRIDE TWO" 

def dontoverride(): 
    basemodule.dontoverride() 
    print "THIS WAS PRESERVED" 

runscript.py

import extmodule 

#code is in extended module 
print extmodule.makeBalls(1,2) 
#returns Ball(1) Ball(2) 

#code is in base module 
print extmodule.makeBall(1) 
#returns Ball(1) 

#function from extended module overwrites base module 
extmodule.override() 
#returns OVERRIDE TWO 

#function from extended module calls base module first 
extmodule.dontoverride() 
#returns THIS WILL BE PRESERVED\nTHIS WAS PRESERVED 

Nie jestem pewien, czy podwójne import w extmodule.py jest python ic - możesz go usunąć, ale nie radzisz sobie z przypadkiem, gdy chcesz rozszerzyć funkcję, która była w przestrzeni nazw modułu bazowego.

W przypadku klas rozszerzonych wystarczy utworzyć nową klasę API (basemodule.API), aby rozszerzyć moduł interfejsu Twitter API.

Answer 2

Nie dodawaj ich do modułu. Podklasuj klasy, które chcesz rozszerzyć i użyj swoich podklas we własnym module, nie zmieniając w ogóle oryginalnego materiału.

Answer 3

Czy mogę zasugerować, aby nie wymyślać tutaj koła? Buduję klienta Twittera> 6k przez 2 miesiące, najpierw sprawdziłem też python-twitter, ale opóźnia się on dużo za niedawnymi zmianami API. Rozwój nie wydaje się być tak aktywny, również było (przynajmniej kiedy ostatnio sprawdzałem) brak obsługi OAuth/xAuth).

Więc po wyszukaniu się trochę bardziej odkryłem tweepy:
http://github.com/joshthecoder/tweepy

Plusy: aktywny rozwój, OAauth/XAUTH i na bieżąco z API.
Szanse są wysokie, że to, czego potrzebujesz, już tam jest.

Więc proponuję jechać z tym, że to działa na mnie, jedyne co musiałem dodać był XAUTH (który dostał scalić z powrotem do tweepy :)

Oh jest bezwstydna, jeśli trzeba analizować tweetów i/lub formatować je do HTML używać wersji Pythona z Twittera na tekście * bibliotek:
http://github.com/BonsaiDen/twitter-text-python

ta rzecz unittestetd gwarancją analizowania tweetów jak Twitter.com to robi.

Answer 4

Say masz starszą moduł o nazwie mod że używasz tak:

import mod 

obj = mod.Object() 
obj.method() 
mod.function() 
# and so on... 

I chcesz go przedłużyć, nie zastępując go dla użytkowników. Łatwo zrobić. Możesz nadać nowemu modułowi inną nazwę, newmod.py lub umieścić go o tej samej nazwie na głębszej ścieżce i zachować tę samą nazwę, np. /path/to/mod.py. Następnie użytkownicy mogą importować go w jeden z następujących sposobów:

import newmod as mod  # e.g. import unittest2 as unittest idiom from Python 2.6 

lub

from path.to import mod # useful in a large code-base 

w module, będziemy chcieli, aby wszystkie stare nazwy dostępnych:

from mod import * 

lub jawnie nazwij każdą importowaną nazwę:

from mod import Object, function, name2, name3, name4, name5, name6, name7, name8, name9, name10, name11, name12, name13, name14, name15, name16, name17, name18, name19, name20, name21, name22, name23, name24, name25, name26, name27, name28, name29, name30, name31, name32, name33, name34, name35, name36, name37, name38, name39 

Myślę, że import * będzie łatwiejszy w utrzymaniu w tym przypadku - jeśli moduł podstawowy rozszerzy funkcjonalność, będziesz płynnie nadążać (choć możesz odcień nowych obiektów o tej samej nazwie).

Jeśli rozszerzany mod ma przyzwoitą wartość __all__, ograniczy importowane nazwy.

Należy również zadeklarować numer __all__ i rozszerzyć go rozszerzonym modułem o numer __all__.

import mod 
__all__ = ['NewObject', 'newfunction'] 
__all__ += mod.__all__ 
# if it doesn't have an __all__, maybe it's not good enough to extend 
# but it could be relying on the convention of import * not importing 
# names prefixed with underscores, (_like _this) 

Następnie rozszerzaj obiekty i funkcjonalność w normalny sposób.

class NewObject(object): 
    def newmethod(self): 
     """this method extends Object""" 

def newfunction(): 
    """this function builds on mod's functionality""" 

Jeśli nowe obiekty zapewniają funkcjonalność zamierzają zastąpić (lub być może jesteś backport nową funkcjonalność do starszego kodu bazowego) można zastąpić nazwy