itty

Код действительно разный, но дело вовсе не в туплах как таковых, что вы к ним привязались.

Потому как законы природы нарушить сложно, даже в питоне

Накладные расходы на вызов функций намного больше, не говоря уже о том что туплы там создаются в C коде.

In [11]: def void(): pass
In [12]: %timeit void()
10000000 loops, best of 3: 121 ns per loop
In [13]: %timeit (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
10000000 loops, best of 3: 27.6 ns per loop

^ создание тупла из 10-ти элементов и его удаление намного быстрее простого вызова функции.

(*) Это конечно хорошо. Просто замечательно. Но опять в теории. А на практике
http://ideone.com/uBa2W
[0] создание константы это одно
[1] создание тупла из констант это другое
[2] создание тупла из переменных значений, что проиходит на самомо деле, в отличие от (*) совершенно уже третье
[3] а в реальной жизни кроме создания и уничтожения тупла нужна его декомпозиция. и уже 6-ти кратное проседание от (*)
[4] а не ровен час декомпозиция ведется через `enumerate` (что тоже вызов функции)
вот и набежало обещанное ранее нивелирование выйгрыша.
но и это не все было еще. тупельная версия использует использует примерно в 2 раза больше декомпозиций через `enumerate`, чем рекурсивная своих рекурсивных вызовов функций.

итого вместо 10-ти кратного ускорения от использования туплов в теории, в реальности имеем 40...400% проседание производительности

Да нет, эквивалентный С код _всегда_ быстрее питона.
Просто видимо в itertools.product внутри не тупо рекурсивный итератор как я думал, и как сделан ваш вариант.

Ключевое слово "эквивалентный". Наш код совершенно разный. Создание и разрушение туплов достаточно дорогая операция по сравнению с рекурсивным вызовом.

Там из itertools используется только product, который просто вроде бы создан для того чтобы быть использованным в данной задаче.
Каюсь, есть привычка в первую очередь использовать библиотеки для любого чиха, но разве это плохо?

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

Работает на порядок быстрее, код стал даже проще.

Понятия не имею что за сферических коней меряет github, но визуально и на ideone рекурсивный метод работает заметно быстрее тупельного.
http://ideone.com/SIcZU
а я даже не начинал его оптимизировать.

Работая с Python никогда нельзя забывать, что C код всегда быстрее...

это все хорошо в теории. а на практике бывает очень по разному.

Один из главных ключей к быстрым программам на Python - знать когда и где можно передать задачу C'шным библиотекам.

вообщето задача была реализовать алгоритм, а не показать виртуозное жонглирование itertools.

Подобную задачу гораздо лучше ( на питоне если ) решить так - http://ideone.com/POXo2
Не нужны ни промежуточные списки ни рекурсия.

зато начинает рождаться астрономическое кол-во туплов, которые нивелируют все теоретические плюсы предложенного решения (даже по скорости). и запаса на оптимизацию у данного решения несоизмеримо меньше чем у моего

http://ideone.com/bI4Bp

так ведь предыдущее ваше решение справляется с этим ,на сколько эффективно я не знаю пусть питонщики скажут)

в предыдущем решении формируется общий список, что при пострениие html таблицы совершенно не требуется. без него получается короче и эффективнее