Windows 7: Использование в своих интересах автоповышения для подъема моего собственного процесса?

У меня есть одно решение ниже, которое работает, но более важным, чем это решение, является несколько комментариев о других подходах. Во-первых, хорошее решение не должно требовать, чтобы один цикл проходил через итераторы по порядку. Если я запускаю

g = paged_iter(list(range(50)), 11))
i0 = next(g)
i1 = next(g)
list(i1)
list(i0)

Соответствующим выводом для последней команды будет

 [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

, а не

 []

, поскольку здесь возвращается большинство решений на основе itertools. Это не просто обычное скучное ограничение доступа к итераторам по порядку. Представьте себе, что потребитель пытается очистить плохо введенные данные, которые поменяли местами соответствующий порядок блоков, равный 5, т.е. данные выглядят как [B5, A5, D5, C5] и должны выглядеть как [A5, B5, C5, D5] (где А5 это всего лишь пять элементов, а не подсписок). Этот потребитель посмотрит на заявленное поведение функции группировки и без колебаний напишет цикл, подобный

i = 0
out = []
for it in paged_iter(data,5)
    if (i % 2 == 0):
         swapped = it
    else: 
         out += list(it)
         out += list(swapped)
    i = i + 1

. Это приведет к загадочно неверным результатам, если вы будете хитро предполагать, что субитераторы всегда полностью используются по порядку. Это становится еще хуже, если вы хотите чередовать элементы из кусков.

Во-вторых, приличное количество предложенных решений неявно основывается на том факте, что итераторы имеют детерминированный порядок (например, они не установлены), и хотя некоторые решения, использующие islice, могут быть в порядке, меня это беспокоит.

В-третьих, подход группирования itertools работает, но рецепт опирается на внутреннее поведение функций zip_longest (или zip), которое не является частью их опубликованного поведения. В частности, функция группирования работает только потому, что в zip_longest (i0 ... in) следующая функция всегда вызывается в следующем порядке (i0), next (i1), ... next (in) перед началом заново. Когда группер передает n копий одного и того же объекта итератора, он полагается на это поведение.

Наконец, хотя решение, приведенное ниже, может быть улучшено, если вы критикуете вышеизложенное предположение о том, что к субтераторам обращаются по порядку и полностью просматривается без этого допущения, он ДОЛЖЕН неявно (через цепочку вызовов) или явно (через запросы или другую структуру данных). ) хранить элементы для каждого подтератора где-нибудь. Так что не тратьте время (как я), предполагая, что можно обойти это с помощью некоторого умного трюка.

def paged_iter(iterat, n):
    itr = iter(iterat)
    deq = None
    try:
        while(True):
            deq = collections.deque(maxlen=n)
            for q in range(n):
                deq.append(next(itr))
            yield (i for i in deq)
    except StopIteration:
        yield (i for i in deq)