|
1 | | -.. module:: github3 |
2 | | -.. module:: github3.structs |
| 1 | +============================ |
| 2 | + Custom Iterator Structures |
| 3 | +============================ |
3 | 4 |
|
4 | | -Structures |
5 | | -========== |
| 5 | +Many of the methods in github3.py that return iterators of another object are |
| 6 | +actually returning one of the iterators below. These iterators effectively |
| 7 | +allow users to ignore GitHub's API pagination of large sets of data. In all |
| 8 | +senses, they behave like a normal Python iterator. Their difference is that |
| 9 | +they have extra logic around making API requests and coercing the JSON into |
| 10 | +predefined objects. |
6 | 11 |
|
7 | | -Developed for github3.py |
8 | | ------------------------- |
9 | | - |
10 | | -As of right now, there exists only one class in this section, and it is of |
11 | | -only limited importance to users of github3.py. The :class:`GitHubIterator` |
12 | | -class is used to return the results of calls to almost all of the calls to |
13 | | -``iter_`` methods on objects. When conditional refreshing was added to |
14 | | -objects, there was a noticable gap in having conditional calls to those |
15 | | -``iter_`` methods. GitHub provides the proper headers on those calls, but |
16 | | -there was no easy way to add that to what github3.py returned so it could be |
17 | | -used properly. This was the best compromise - an object the behaves like an |
18 | | -iterator regardless but can also be ``refresh``\ ed to get results since the |
19 | | -last request conditionally. |
20 | | - |
21 | | -Objects |
22 | | -------- |
23 | | - |
24 | | -.. autoclass:: GitHubIterator |
| 12 | +.. autoclass:: github3.structs.GitHubIterator |
25 | 13 | :inherited-members: |
26 | 14 |
|
27 | | - |
28 | | -.. autoclass:: SearchIterator |
| 15 | +.. autoclass:: github3.structs.SearchIterator |
29 | 16 | :inherited-members: |
0 commit comments