Воженные функции

Если язык позволяет, я бы предпочел второй вариант, чтобы не засорять интерфейсы.

позволяет,по тем же соображениям что и у вас склоняюсь ко второму варианту

Первое будет читабельнее и проще в поддержке.

if

Первый вариант. “Flat is better than nested”. Другим методам класса может понадобится вызывать специфический алгоритм.

if слишком громоздкий получится

Чтобы не создавать эти две функции при каждом вызове общей функции, используй замыкание и декоратор.

def _decor(f):
    def foo1(a):
        ...
        return res
    def foo2(a):
        ...
        return res
    def wrapper(a):
        if check(a):
            return foo1(a)
        else:
            return foo2(a)
    return wrapper

@_decor
def bar(a): pass

Кстати да это соображение из zen of python сюда подходит, однако насчет 2-го соображения: для данной программы можно гарантировать, что другие методы класса эти внутренние алгоритмы вызывать не будут

Спасибо, кстати о декораторах я и не подумал

Первый по мне так лучше с точки зрения возможности самостоятельного выбора алгоритмов и возможности их тестирования.

Либо можно спрятать из поля видимости две функции в классе, а к функции обертки ещё добавить дополнительный параметр выбора алгоритма со значением по умолчанию, вида, XXXAuto.

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

Посмотри ещё сюда: https://qt.gitorious.org/qt/qt/blobs/4.8/src/gui/image/qimage.cpp

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

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

Сделал по первому варианту

if слишком громоздкий получится

Пуркуа? Если там нетривиальные условия выбора алгоритма, то:

def mymethod( self, ... ) :
   mode = .....
   if mode : # alg1
   else : #alg2

По числу строчек так будет ровно то же самое, по читаемости - ИМНО куда прозрачней. Вложенные ф-ии имеют свои особенности, декоратор для этого припахивать так вообще... явный синдром аспектного программирования ГМ;-)

Еще кстати не обязательно делать ф-ю методом класса, она м.б. просто обычной ф-ей модуля принимающей аргументом self экз. класса, и не экспортироваться из модуля по дефолту.

Под громоздкостью ТС видимо подразумевал тот простой факт, что ветки alg1 и alg2 будут иметь лишний уровень оступов по сравнению с вариантом вынесения их в отдельные функции. «Плоское лучше вложенного» и всё такое. Кроме того, если алгоритмы расписаны на много строк, базовая функция распухнет. Пассаж про синдромы оставлю без комментариев.

Ну если отступы заботят, эти ф-ии надо вообще внешними делать.

Про синдромы не обижайтесь - там стоял смайлик.

Согласен с вами, она действительно сильно распухнет, если писать «все в одном»