Qu'est-ce que c'est, n'y a-t-il pas un bon message envoyé? Il semble y avoir un bon message «connecté». J'étais un peu soulagé. Pour la méthode appelée depuis on_data, il semble qu'elle sera déconnectée si la valeur de retour est False. on_error est implémenté pour retourner False s'il n'est pas remplacé. Cela ne peut être vu qu'en regardant la classe Stream et en vérifiant l'appelant.

À propos, les messages envoyés par Stream API sont publiés sur dev.twitter.com . Cependant, il semble que les messages "status_withheld", "user_withheld", "scrub_geo", "for_user" et "control" ne sont pas vérifiés par on_data. Est-ce parce que cela n'a pas beaucoup de sens? Si vous voulez les voir, vous devez remplacer on_data et remplacer la plupart des méthodes ci-dessus. Je ne sais pas.

Classe de flux

Cela ressemble à une classe qui implémente des boucles de connexion, de déconnexion et de réception. Définissez les paramètres initiaux de connexion avec "init (constructeur)" et appelez les méthodes correspondant à l'API Stream de "userstream", "firehose", "retweet", "sample", "filter" et "sitestream" pour passer par "_start". Appelez "_run".

La boucle de "while self.running:" effectue un traitement de connexion spécifique, et la boucle d'exécution après connexion est gérée par "_read_loop". Si le processus de connexion échoue avec "self.session.request ()", appelez on_error de la classe StreamListener, sortez de la boucle While dans le cas de False et reconnectez-vous en attendant un certain temps tout en tournant le compteur d'erreurs dans les autres cas ...

** N'y a-t-il pas une fonction de reconnexion! ** **

C'est vrai, il n'y a aucune raison de ne pas implémenter l'histoire gênante dans la bibliothèque. Ce n'est pas une histoire de laisser l'utilisateur le faire.

L'obstacle est soudainement tombé pour la spécification d'exigence la plus importante, "** Une fonction à reconnecter en cas de déconnexion inattendue **". Par contre, je voudrais demander une heure pourquoi les détails de ces fonctions importantes ne sont pas décrits de manière facile à comprendre ...

Par ailleurs, dans "\ _read_loop", "on_data" de la classe StreamListener est appelé, et si False est renvoyé ici, la boucle est échappée. A ce moment, self.running dans lequel False est stocké est également vu dans la boucle de connexion de l'appelant "_run", et la boucle de connexion est quittée et la session est terminée.

Regardez la source et décidez d'une politique.

prendre le coeur. En regardant la source

1. La méthode qui part de on_data de la classe StreamListener est déconnectée et se termine lorsque False est renvoyé.
   → Remplacez tout ce qui renvoie False dans la méthode d'origine pour qu'elle renvoie True.
2. Lorsque on_error et on_timeout renvoient False, ils se terminent sans se reconnecter.
   → Remplacez ceci et renvoie True.
3. on_exception ne peut pas être traité, alors pensez à des moyens

En regardant spécifiquement la source, il n'y a rien qui correspond à (1). Je veux dire, il ne renvoie pas True ou False comme valeur de retour. ...... Est-ce que c'est correct? * Je vérifie avec "est faux:", donc c'est OK * parce que ce n'est pas égal en comparaison quand la valeur ne revient pas? Concernant (2), on_timeout ne retourne pas de valeur et retourne, donc c'est OK si vous remplacez seulement on_error et retournez True. (3) Que dois-je faire?

Cependant, pour les avertissements comme pour les erreurs, il semble qu'il sera utile de conserver un journal plus tard, alors écrasez "on_connect" "on_disconnect" "on_limit" "on_timeout" "on_warning" "on_exception" À

Traiter les exceptions

Les exceptions sont des exceptions, il est donc difficile de les gérer. L'exception dans la boucle de traitement de la classe Stream est déclenchée après l'appel de on_exception de StreamListener, il devrait donc être possible de l'exclure au niveau de l'appelant. Sinon, que se passe-t-il si cela se produit pendant le traitement individuel dans StreamListener? Cependant, si vous suivez l'appelant, ce sera un StreamListener, donc il finira par s'y rassembler ...? S'il s'arrête toujours avec une exception ... Souhaitez-vous appeler le script en boucle avec un fichier batch? ??

Source jusqu'à présent

Sur la base de la priorité absolue "** Possibilité de se reconnecter en cas de déconnexion inattendue **", la source ressemble jusqu'à présent à ceci.

tweetcheck2.py

#!/usr/bin/env python
# -*- coding:utf-8 -*-

import tweepy

#Obtenez-le vous-même et mettez-le
CK = ''   # Consumer Key
CS = ''   # Consumer Secret
AT = ''   # Access Token
AS = ''   # Accesss Token Secert

class Listener(tweepy.StreamListener):
    def on_status(self, status):
        print('Tweet')    #Je ne peux pas le lire de toute façon, donc je vais juste vous dire qu'il y avait un message
        return True

    def on_error(self, status_code):
        print('Erreur est survenue: ' + str(status_code))
        return True

    def on_connect(self):
        print('Connecté')
        return

    def on_disconnect(self, notice):
        print('Débranché:' + str(notice.code))
        return

    def on_limit(self, track):
        print('La limite de réception s'est produite:' + str(track))
        return

    def on_timeout(self):
        print('temps libre')
        return True

    def on_warning(self, notice):
        print('Message d'alerte:' + str(notice.message))
        return

    def on_exception(self, exception):
        print('Erreur d'exception:' + str(exception))
        return


#Traitement principal d'ici
auth = tweepy.OAuthHandler(CK, CS)
auth.set_access_token(AT, AS)

while True:     #boucle infinie
        try:
                listener = Listener()
                stream = tweepy.Stream(auth, listener)

                #Sélectionnez-en un et décommentez-le.
                #stream.filter(track=['#xxxxxx'])
                stream.sample()
                #stream.userstream()
        except:
                pass    #Ignorer toutes les exceptions et boucle

Assurez-vous d'afficher tous les messages qui menacent l'exécution, tels que les erreurs et les avertissements, et reconnectez-vous si une erreur se produit. Dans le cas peu probable où une exception se produirait, la section de traitement principale l'exclura, ignorera l'exception, la bouclera et la réexécutera.

Fini? …… Ctrl + C …… </ petit>

(Quand je l'ai essayé, je ne pouvais pas l'arrêter (stupide. Y a-t-il un moyen d'échapper à la boucle uniquement lorsque Ctrl + C?)

La forme de base du traitement lié à Twitter est probablement comme ça pour le moment. Je me demande si c'est vraiment bien, mais ... ** Je cherche Tsukkomi . La prochaine fois, je commencerai du côté MongoDB, la priorité la plus élevée, " Stockage des données reçues dans MongoDB **". (Continuer)