мм… что конкретно? на данный момент есть pep-3333, описывающий инженерное решение заморочек для python3. т.е., если не впадать в научный креативизм (имею ввиду pep-0444 от Армина), можно сделать всё уже прямо сейчас.
В питоне нормальные неймспейсы и система импортов, статические методы классов поэтому там редко когда нужны.
термин «статический метод» из ООП — это самостоятельная штука, которая ортогональна и неймспейсам, и модулям. в подмене одного понятия на другие нет причинно-следственной связи — они все абсолютно нормальные, в своих понятийных областях. ООП предлагает чёткий логический фреймворк для структурирования кода, и к каким последствиям приведёт такое замещение, предсказать сложно.
думаю, хорошим контр-примером здесь служит Django, которая очень активно пытается использовать систему питонячих модулей, для структурирования ООП-кода, и каким заморочкам это приводит на практике. мм. т.е. известно к каким — при таком подходе к зависимостям от интерфейса, добавляются зависимости от неймспейса (читай — конкретных библиотек) — в результате чего код намертво привязывается к конкретной реализации.
тогда прошу прощения, я не правильно понял тезис. вот только рельсы, в этом отношении, смотрятся ещё привлекательнее, за счёт более тесной интеграции с рубячей инфраструтурой (gems, rake и т.д.). :)
Django реально выматывает своей политикой релизов. с одной стороны, они вроде бы тащат за собой кучу deprecated и legacy кода, с другой — всё равно ломают обратную совместимость в самых неожиданных местах.
у меня нет возможности установить на удалённой машинке X и нужный зоопарк браузеров. можно-ли выполнять питонячьи тесты с selenium на удалённом сервере, используя браузеры, запущенные где-то в другом месте?
я как раз из тех, кто много слышал про монады, но так и ничего не понял. :) спасибо за ваши статьи, создаётся ощущение, что вот оно, прозрение, уже совсем близко. отметил, что теперь примеры, чисто внешне, стали напоминать код для jQuery, где функции должны всегда возвращать этот чудо-объект. :)
говорят, что достоинства или недостатки той или иной архитектуры определяются тем, насколько хорошо в ней локализуются изменения при изменении требований. как вы считаете, как много придётся менять в примере с птицами, чтобы сообщать причину и место падения пользователю явно (которые в примерах указаны комментариями)?
в классическом ООП я бы решал эту задачу при помощи специализации «управляющей коробки» (class TightropeWalkerProblem(Maybe): ... ). допустимо-ли подобное для монад? похоже, что изменение монады, каскадом, заставит изменять и все монадические функции, которые с ней связаны — возможно, лишь для того, чтобы они стали возвращать монадические значения нового типа. скорее всего, это не оптимальное решение, а правильное от меня ускользает.
Функция, которая принимает обычное значение и возвращает результат в контексте (монадное значение), называется монадной функцией
не как могу сообразить, что к чему в примере с конями. в строчке:
List(pos) +'>>='+ raw_jumps +'>>='+ if_valid
функция raw_jumps используется совместно с оператором '>==' из монады List, значит она должна быть монадической.
по определению, функция raw_jumps должна принимать обычное значение координат, и возвращать результат в контексте (т.е. List(result)). но если посмотреть код выше, то функция определена иначе:
raw_jumps = lambda (x, y): [ ... ]
т.е. принимая координаты, функция возвращает объект встроенного типа list, который к монаде List не имеет отношения. или имеет? в чем магия?
Опишите простым и понятным языком, как взаимодействует пользователь с вашим приложением. Затем запишите все то же самое на алгоритмическом языке. Получите тест. Для большинства начинающих уже первый этап становится серьезным испытанием. :)
в данном примере нет итерации по списку. ;)
возможно, чтобы исключить путаницу, авторам нужно было воспользоваться collections.deque для реализации стека, а не list.
>Не очевидно, что метод test может принадлежать не классу Device (например, Device.init может возвращать объект Dispenser). А выглядит это так, будто Device.test существует.
определяющим фактором для fluent интерфейсов является сохранение контекста между вызовами методов (т.е. то, что метод возвращает self, а не что-то другое). поэтому en.wikipedia.org/wiki/Law_of_Demeter не нарушается и ни какой путаницы быть не может.
по большому счёту, смысл всей этой затеи состоит в том, чтобы упростить выражение, «вынеся за скобки» повторяющееся имя переменной. такое повторение часто получается при конфигурировании объектов.
существуют примеры реализации данного паттерна на уровне языка. например в VisualBasic, где программисты проводят массу времени, занимаясь конфигрурированием объектов:
With testObject
.Height = 100
.Text = "Hello, World"
.ForeColor = System.Drawing.Color.Green
.Font = New System.Drawing.Font(.Font, System.Drawing.FontStyle.Bold)
End With
В данном случае не нужно говорить «клиент» — такая подмена понятий приводит к искажению смысла (и нарушению инкапсуляции)). Если это происходит на практике, то неизбежно создаёт ситуацию когда «scrum не подходит». Вверять неподготовленному клиенту постановку продуктовых задач и взаимодействие с командой не только неразумно, это просто опасно.
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.
по правде говоря, я не до конца понял, область применимости решения, предложенного в топике. Если речь идёт об учёте действий пользователей в системе, то модели об этом аспекте, в идеале, не должны знать ни чего (иначе, как ответить на вопрос «кто удалил объект?»), — тема интересна, но данное решение не подходит. Если же взаимодействие пользователя с моделью существенно, с точки зрения бизнес-логики, значит оно должно быть отражено в публичном интерфейсе модели — в таком случае пользователь будет передаваться явно, и threadlocals нафик не нужен.
Возможно, что threadlocals как лакмусовая бумажка, показывает потенциально опасные места в архитектуре. Меня настораживает, что предложенное решение привязывает модель к HTTP запросу. Т.е. пока модель используется сугубо как «штука, которая должна сохранять информацию из http запроса», всё здорово. Но если возникнет необходимость использовать модель из другого контекста — например, из консольной команды, где ни какого request нет и в помине — не знаю как в Pylons, но в Django будут заморочки, т.к. стек middleware в таком случае не отрабатывает.
это может быть решением. замечу только, что это чревато. ведь религиозная война на тему, почему так делается, например, в Pylons, и не делается в Django ещё не закончена). разработчики фреймворка вполне сознательно отключили профильную статью в своей вики code.djangoproject.com/wiki/CookBookThreadlocalsAndUser, где что-то подобное было описано.
термин «статический метод» из ООП — это самостоятельная штука, которая ортогональна и неймспейсам, и модулям. в подмене одного понятия на другие нет причинно-следственной связи — они все абсолютно нормальные, в своих понятийных областях. ООП предлагает чёткий логический фреймворк для структурирования кода, и к каким последствиям приведёт такое замещение, предсказать сложно.
думаю, хорошим контр-примером здесь служит Django, которая очень активно пытается использовать систему питонячих модулей, для структурирования ООП-кода, и каким заморочкам это приводит на практике. мм. т.е. известно к каким — при таком подходе к зависимостям от интерфейса, добавляются зависимости от неймспейса (читай — конкретных библиотек) — в результате чего код намертво привязывается к конкретной реализации.
говорят, что достоинства или недостатки той или иной архитектуры определяются тем, насколько хорошо в ней локализуются изменения при изменении требований. как вы считаете, как много придётся менять в примере с птицами, чтобы сообщать причину и место падения пользователю явно (которые в примерах указаны комментариями)?
в классическом ООП я бы решал эту задачу при помощи специализации «управляющей коробки» (
class TightropeWalkerProblem(Maybe): ...). допустимо-ли подобное для монад? похоже, что изменение монады, каскадом, заставит изменять и все монадические функции, которые с ней связаны — возможно, лишь для того, чтобы они стали возвращать монадические значения нового типа. скорее всего, это не оптимальное решение, а правильное от меня ускользает.не как могу сообразить, что к чему в примере с конями. в строчке: функция
raw_jumpsиспользуется совместно с оператором'>=='из монадыList, значит она должна быть монадической.по определению, функция
raw_jumpsдолжна принимать обычное значение координат, и возвращать результат в контексте (т.е. List(result)). но если посмотреть код выше, то функция определена иначе: т.е. принимая координаты, функция возвращает объект встроенного типа list, который к монаде List не имеет отношения. или имеет? в чем магия?возможно, чтобы исключить путаницу, авторам нужно было воспользоваться collections.deque для реализации стека, а не list.
определяющим фактором для fluent интерфейсов является сохранение контекста между вызовами методов (т.е. то, что метод возвращает self, а не что-то другое). поэтому en.wikipedia.org/wiki/Law_of_Demeter не нарушается и ни какой путаницы быть не может.
по большому счёту, смысл всей этой затеи состоит в том, чтобы упростить выражение, «вынеся за скобки» повторяющееся имя переменной. такое повторение часто получается при конфигурировании объектов.
существуют примеры реализации данного паттерна на уровне языка. например в VisualBasic, где программисты проводят массу времени, занимаясь конфигрурированием объектов:
В методологии scrum взаимодействие команды и невовлечённых представителей клиента (stakeholders, скажем) случается не часто и очень жестко регламентируется. Обычно команда взаимодействует с человеком, играющим конкретную роль — «Product Owner». PO это разумная прослойка между клиентом и разработчиками, которая конвертирует «хотелки» бизнеса, в требования, задачи и приоритеты, соответствующие продукту и понятные команде. Очевидно, что для этого нужно «быть в теме», и не всякая «манагерша проекта» способна играть роль PO.
Если строить аналогию, то PO как водитель автомобиля. Он должен разбираться в бизнесе примерно в той же мере в какой водитель — ориентироваться в городе. Он должен учитывать особенности продукта и команды в той же степени, в какой водитель учитывает особенности вверенного ему механизма. Т.е. с одной стороны — знать как из точки A попасть в точку Б, наиболее эффективным образом, не намотав лишние километры и не простояв лишние часы в пробках. С другой — не трогаться с места включив 5-тую передачу, не смотря на то, что она самая быстрая, планировать не только поездки, но и заправки, а так же время для мойки и тех.обслуживания.