Пайпы, the pythonic way

супер

Утрированный пример на самом деле решается так:

my_function(sum(x for x in xrange(100) if x % 3 == 1))

По сравнению с:

[x for x in range(100)] | where(lambda x: x % 3 == 1) | sum | my_function

Это действительно гениально, причем и как идея, так и реализация! Я в восторге!
Обязательно начну использовать у себя.

Главное — создать свой объект, т.к. в Питоне нельзя расширять предопределённые типы :(((. А трубы — это по практически то же, что и вызов методов:

[1,2,3,4] | where(lambda x: x<=2) | as_list

легко реализуется «питоническим» способом как:

KribleKrable([1,2,3,4]).where(lambda x: x<=2).as_list()

Сомнительный запашок у получающегося кода.

Перегрузка операций (любых) — не самый лучший способ построения каскадов генераторов.
Из-за этой перегрузки в записи возможны досадные ошибки.

Понятность снижается (а должна бы увеличиваться).
Оператор | может встречаться и в привычном контексте битовых операций.
Здесь же придется внимательно смотреть: это pipe или нет?
Если, скажем, numpy перегружает операторы для матриц — там ясна предметная область и не происходит
её перекрытия со стандартной семантикой. Если складываются два числа — они делают это по правилам элементарной арифметики. Две матрицы — тоже ничего нового.
В sqlalchemy для SQL запросов перегружаются все битовые операции.
При этом биты для чисел и запросы для SQL разведены по разным углам, очень редко пересекаясь в коде. По выражению практически всегда легко понять, где кто.
Здесь же | работает как битовый для чисел и pipe в стиле bash если самый правый операнд оказался типа Pipe.
Семантика разная, и две семантики легко могут пересекаться. Это неприятно.

Еще одно: эту штуку крайне легко сломать.

import pipe

class L(object):
    def __init__(self, v):
        self.v = v

    def __or__(self, r):
        return 'abra'

print L(range(5)) | pipe.as_list

Вроде бы класс L вполне невинен. Только, на беду, содержит оператор __or__, приоритет которого выше чем у
__ror__. Нехорошо…

Не все возможные занятные выкрутасы стоит использовать.

Сугубо личное мнение. Если кто не согласен — навязывать свое мнение не буду.
Раньше мне тоже нравились подобные полеты мысли: чем замудрённей — тем интересней.
Сейчас скорее признаю предлагаемый код unpythonic.

Это всё, конечно, интересно и красиво, но я бы долго моргал глазами, если бы увидел это в чужом коде.
И я уже молчу про проблемы, описанные Андреем: к чёрту этот блек-джек!
Можно было бы подумать о такой организации настоящих пайпов модуля subprocess, но нужно хорошо подумать…

Заметной разницы нету, кроме обращения порядка действий. В идеале хотелось бы что-то вроде $ в haskell — порядок остается тем же, а скобки писать не надо

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

wtf = compose([where(lambda x: x % 3 == 1),
               sum,
               my_function])

result = wtf(x for x in range(100))

удобно если планируется реиспользовать функцию, хотя немного громоздко для однострочников. «библиотека», в первом приближении:

from functools import partial

compose2 = lambda f, g: lambda *args, **kws: g(f(*args, **kws))
compose = partial(reduce, compose2)
where = partial(partial, filter) # %) ?

Коллеги,

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

Комфортный синтаксис может быть необходимостью только в каком-то более широком контексте: фреймворке, бОльшей билиотеке, для каких-либо специальных задач.

Этот декоратор — proof of concept, не более того. Но красивый, тем и понравился :)

Хм…

Post.objects | where(user_id = 1) & where(is_published = True) | order('-time_published') | by_page(1, 10)

Забавно выходит :)

Ваша статья натолкнула меня на некоторые мысли в контексте Ruby.

В нем проблемы с пайпами как таковой нет:

my_function(sum(filter(lambda x: x % 3 == 1, [x for x in range(100)])))

записывается как:

my_function ((1..100) . to_a . keep_if {|x| x % 3 == 1 } . reduce(:+))

Но с генераторами вида:

def fib
  a, b = 0, 1
  loop do
    yield a
    a, b = b, a + b
  end
end

fib . take_while {|x| x < 10}

такое уже не проходит.

Приходится немножко извращаться:

def fib
  a, b = 0, 1
  res = []
  loop do
    return res unless yield a
    res << a
    a, b = b, a + b
  end
end

fib {|x| x < 10} # => [0, 1, 1, 2, 3, 5, 8]

Неплохо, но хочется-то предыдущий вариант! :)

Конечно, можно использовать Fiber, дополнив его методом take_while:

class Fiber
  def take_while
    res = []
    loop do
      val = self.resume
      return res unless yield val
      res << val
    end
  end
end

def fib
  Fiber.new do
    a, b = 0, 1
    loop do
      Fiber.yield a
      a, b = b, a + b
    end
  end
end

fib . take_while {|x| x < 10} # => [0, 1, 1, 2, 3, 5, 8]

Работает. Но что же это получается: каждую функцию, от которой требуется свойство бесконечного генератора, внутри оборачивать в Fiber? Noway! Я слишом ленив для такого.

И тут мой взор упал на декораторы питона: «Хорошая штука» — подумал я, сейчас возьму такую же в любимом руби и… внезапно в Ruby такого не оказалось.
«Вещь то полезная… надо реализовать!» — подумал небезызвестный Yehuda Katz и забацал поддержку декораторов для руби в 80 строчек кода.

Пишем свой декоратор:

class Generator < Decorator
  def call(this, *args)
    Fiber.new { loop { @method.bind(this).call(*args) { |x| Fiber.yield x } } }
  end
end

и класс для бесконечного генератора чисел фибоначчи с «чистым» методом fib:

class FibGen
  extend MethodDecorators

  Generator()
  def fib
    a, b = 0, 1
    loop do
      yield a
      a, b = b, a + b
    end
  end
end

FibGen.new.fib . take_while {|x| x < 10} # => [0, 1, 1, 2, 3, 5, 8]
FibGen.new.fib . take(7) . map {|x| x * 2} . reduce(:+) # => 40

Отлично! :)

Итого: добрая половина дня убита занятием вот этой замечательной фигней ^.^

Вижу, разгорелся небольшой спор о том, что такое pythonic и что — нет.
Четкого определения нет и быть не может.
Мое чутье основывается на многолетнем чтении рабочей переписки разработчиков питона.
И на собственном опыте, конечно.
Иногда вроде бы красивая идея отвергается по результатам обсуждения.
Причины бывают разные.
Например, предлагаемый подход работает не в том духе, в котором сделано все остальное. Это может вводить пользователя в недоумение. В малых дозах — не страшно. В больших — становится натуральным ядом.
Случается и другое: работает в большинстве очевидных случаев, но в «темных углах» поведение непредсказуемо. Более того, правильное поведение неочевидно. Или мнения делятся «пополам-на-пополам».
Значит — решение плохое. Его можно применять в сторонних библиотеках — но в стандарт оно не войдет.
Бывает и третье. Все хорошо и понятно. Во мнениях сошлись. Но генерируемые ошибки (логичные и понятные) — неочевидны. Хороший спец понимает их с полуслова. «Простой программист» теряется в догадках. Это — тоже весомый минус. Предложение не будет принято.
Иногда ван Россум говорит: «Жопой чую, что-то здесь не так. Давайте отложим решение до лучших времен. И еще раз подумаем».

Это — строгие критерии отбора в core development team. Сторонние библиотеки не обязаны им следовать.

Более того. Уверен, что я перечислил далеко не все случаи — просто вспомнил о наиболее очевидных.

Что такое pythonic или unpythonic каждый решает сам для себя. И, тем не менее, я стараюсь следовать «чувству правильного», которое крайне неочевидно. Ориентир — тот дух, что пропитывает решения создателей языка.
Не одна моя поделка при внимательном рассмотрении оказалась — unpythonic. Красивая и лаконичная запись — и затем море проблем. Что-то улучшалось, гораздо большее — выбрасывалось. Жаль, но так лучше…

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

В сочетании с ipython это просто шикарно для использования в качестве оболочки командной строки.

Ох, если нужно писать понятно, то лучше уж писать «четверостишиями» действительно длинные связки, тогда названиями переменных можно одновременно и код документировать.