I'm not sure if I understand correctly: the limit parameter is used to upper limit the number of tweet items, but based on the actual running situation, this limit and the actual number of items obtained differ by about 1 time (specifically, it depends on the actual return of twitter, and in most cases, each cursor returns 102 items).
I referred to the _paginate function under file account.py, although I'm not very clear about the role of DUP_LIMIT, but I found that the count of rest_id is related to the limit parameter, but it doesn't accurately reflect the upper limit provided by the limit parameter.
I want to confirm whether this is a problem or a feature, why use rest_id as a counter label instead of, for example, sortIndex (this key is very robust in all request types) and whether it will be improved in the future here.
I'm not sure if I understand correctly: the
limitparameter is used to upper limit the number of tweet items, but based on the actual running situation, this limit and the actual number of items obtained differ by about 1 time (specifically, it depends on the actual return of twitter, and in most cases, eachcursorreturns 102 items).I referred to the
_paginatefunction under fileaccount.py, although I'm not very clear about the role ofDUP_LIMIT, but I found that the count ofrest_idis related to thelimitparameter, but it doesn't accurately reflect the upper limit provided by thelimitparameter.I want to confirm whether this is a problem or a feature, why use
rest_idas a counter label instead of, for example,sortIndex(this key is very robust in all request types) and whether it will be improved in the future here.