Guido van Rossum о паттернах в Питоне, своей работе в Гугле и Питоне-3000

> Зачем вам такой изврат? Или цель именно потрахаться? :)

Это не мне. Это Гвидо с какого-то перепугу понадобилось объяснять, как вышивать крестиком на питоне. Мне тоже непонятно, зачем ему такой изврат.

> Хотя сколько лет живу, ни то, ни другое до сих пор не понадобилось.

Да и мне понадобилось ровно один раз, в VB, если не считать определения объектных констант в Эйфеле.

Давайте разделим нашу дискуссию на две части:

а) чем отличается синглетон от утилиты, и почему питоновские модули -- это скорее утилиты, чем синглетоны?

б) нахрена это все нужно?

Пункт а) -- сугубо концептуальный, причем только для языков, где класс не есть first-class-object, простите за каламбур. То есть, это важно в C++, Java, C# и Eiffel, но неактуально в Python, Lisp и (кажется) Ruby. Ибо если с классом можно манипулировать, как с объектом, то его можно представлять себе, как свой собственный синглетон. А если таковое недопустимо, то приходится различать случаи, когда Вы создаете хотя бы один экземпляр класса (синглетон), или когда Вы его таки не создаете, а используете только его статические (разделяемые) атрибуты.

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

По второму вопросу, как я понял, разногласий у нас вообще не наблюдается.

Консенсус?

Хотя Borg проще: =)

# этот ужос пишется один единственный раз и прячется в модуль
class Borg(type):
    def __new__(cls, name, bases, clasdict):
        clasdict.setdefault('_shared_state', {})
        return type.__new__(cls, name, bases, clasdict)
    def __call__(cls, *args, **kwds):
        self = cls.__new__(cls, *args, **kwds)
        self.__dict__ = self._shared_state
        cls.__init__(self, *args, **kwds)
        return self

#дальше всё просто:
from borg import Borg
class Spam:
    __metaclass__ = Borg
    ...
    ...
    ...

> "Дочерний" модуль будет импортировать из "базового" модуля базовый класс, наследовать от него свой класс и создавать при инициализации его объект. Модули здесь - просто контейнеры, гарантирующие уникальность.

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

>>Ыгы, ваще отстой, когда любой бивень твой код понимает с первого взгляда! То ли дело s/\/\/\/\//\\\\\\\\/!

Пример кода и в правду ронят под стол :))

а) чем отличается синглетон от утилиты и почему питоновские модули -- это скорее утилиты, чем синглетоны?

> В общем, как я уже сказал, вопрос скорее концептуальный.

Теперь понимаю, вы больше значения придавали концепциям и терминологии стороне, а Гвидо (и меня) больше интересовала практика. Вот на практике с большей частью задач, для которых и придумали синглетоны, легко справляются модули. Но естественно, модули отличаются от синглетонов, и да, скорее утилиты. Дальше спорить, вроде бы, не о чем. :)

> import mysingleton

> a = mysingleton > b = mysingleton

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

a = import mysingingleton

или даже

(import mysingleton).myroutine

А то и вообще:

mysingleton().myroutine

В том смысле, что все эти import не нужны. Хотя, их тоже можно считать частью узора :-).

> Гвидо (и меня) больше интересовала практика

Тогда выступление Гвидо вообще непрактично, ибо рассказывает, как решать на Питоне проблемы такого языка, как Java.

> a = import mysingingleton

import mysingleton as a не устроит?

Хотя, мне и самому не нравится, что import - оператор, да ещё и со странной семантикой. Есть, правда, функция-полуфабрикат __import__(name, globals, locals, fromlist) -> module, из неё можно сделать что-то хорошее, но почему-то никто никогда не делает. :)

> Тогда выступление Гвидо вообще непрактично, ибо рассказывает, как решать на Питоне проблемы такого языка, как Java.

Цитата:

"Сначала г-н ван Россум провел небольшую рекламную кампанию Питону, рассказав о нем как о "выполняемом псевдокоде", о легкости интеграции с другими решениями, с полиморфизмом а-ля "duck typing", с широкими и узкими интерфейсами и другими особенностями языка. И только после этого перешел к самим паттернам.

Так, он упомянул, что много паттернов выглядят в Питоне по-иному, чем, например, в Java. Некоторые вообще исчезли за ненадобностью или уже встроены в язык (как factories, iterators). Такая особенность языка, как dynamic dispatch значительно упрощает множество паттернов, таких как, к примеру proxy и visitor."

А потом жаббщики таки стали донимать его своими синглетонами, и чтоб не тратить время на убогих, он сказал, что и такое в Питоне бывает. А как бы вы им ответили? :)

to eugine_kosenko

В питоне есть мультиимпорт
import sys,os as xyz,string
поэтому import ничего и не возвращает.

Вопрос к любителям перла.

Есть ли там следующие вещи:
Контроль доступа к атрибутам - аналоги 
__getattr__,__setattr__,__delattr__
class X(object):
    def __getattr__(self,name):
        return "%r is absent" % name

t = X()
print t.g  # => 'g' is absent
t.g = 10
print t.g  # => 10

Перегрузка операторов(+ - () [] ....).
Множественное наследование.
properties
Статические и классовые методы.
Можно ли их использовать например с SOAP,CORBA,COM и сколько для 
етого придется кода написать?
Есть ли для них OORM? Короче насколько эти объекты удобны для 
использования с современными OOП технологиями?
И что же там такое есть чего по ваш. мнению нет в питоне?

По пов. библиотек - AFAIK нет не только sci но и как уже сорок раз писалось, Wx,Qt,Pyro(OORPC),Django,Zope,SQLAlchemy(OORM)(для последних трех ессно аналогов).Ну и еще кучки.

Забыл написать что это по поводу объектных систем в перле а не базового языка (

Так и запишем п..ш не перл - но его не знаешь. По всем твоим вопросам (кроме модулей - кури cpan) есть ответы в perldoc. Ты просто ламер. За перезагрузку операторов ИМХО, надо убивать. И вообще

> И только два рубиновых скрипта незыблемы ) Это, я так понимаю, в Амароке ? )))

Какой еще такой амарок?

Это /usr/bin/erb и /usr/bin/testrb из самого руби.

>модуль и не класс -- его невозможно унаследовать

Вопрос: чем отличается от наследования такое:

>cat ПОТОМОК.py

from ПРЕДОК import *
import ПРЕДОК as self
#и переопределяем/параметризуем что нам нужно

> Так и запишем п..ш не перл - но его не знаешь

Я про перл не пишу, а спрашиваю. Копаться в очередном полураритете неохота и времени нет. Зато по тону ответа я понимаю что описанного нифига нет, и след. ООП в перле тоже нет, а описанные раннее модели - лажа.

> кроме модулей - кури cpan

Впирьот. Покажи мне сайты указанных модулей(хотя-бы половины), великий знаток cpan.

> Ты просто ламер

Сложно ответить - определение ламера в студию, а заодно доказательство на основании предыдущего поста данного тезиса.

> За перезагрузку операторов ИМХО, надо убивать

Понятно. Очередной отморозок взялся писать о программировании. Если ты сам еще не дорос, то посмотри как большие и умные дяди сделали во всех остальных языках - даже fortran прикрутил перегрузку операторов. Говорить про С++,Java,Python,Ruby,C# etc я так понимаю не стоит - это вообще черная магия.

И чем это не параметризованый модуль

>cat module.py

def init(**params):
  globals().update(params)
  del globals()['init']

>cat usage.py

import module
module.init(параметры)

>Какой еще такой амарок?

Это /usr/bin/erb и /usr/bin/testrb из самого руби.

LOL

По поводу модулей и объектов. (Это из ipython In - это то что вводится Out - вывод интерпретатора)

In [20]: import sys In [21]: sys.__class__ Out[21]: <type 'module'> In [23]: module = sys.__class__ In [24]: ?module

Type: type Base Class: <type 'type'> String Form: <type 'module'> Namespace: Interactive Docstring: module(name[, doc]) Create a module object. The name must be a string; the optional doc argument can have any type.

In [25]: class MyExtendedModule(module): ....: def fff(self): ....: print "ffff" ....: In [27]: g = MyExtendedModule("new_module") In [28]: g Out[28]: <module 'new_module' (built-in)> In [30]: sys.modules['my_new_module'] = g In [31]: import my_new_module In [32]: my_new_module.fff() ffff

Для тех кто не силно знаком с питоном. Имортировал модуль sys. Взял его класс, унаследовался от него,расширив методом fff. Затем зарегистрировал экземпляр этого модуля. А потом импортировал его-же стандартными средствами. А в перле так можно?

По поводу модулей и объектов.
(Это из ipython 
In - это то что вводится
Out - вывод интерпретатора)

In [20]: import sys
In [21]: sys.__class__
Out[21]: <type 'module'>
In [23]: module = sys.__class__
In [24]: ?module

Type:           type
Base Class:     <type 'type'>
String Form:    <type 'module'>
Namespace:      Interactive
Docstring:
    module(name[, doc])
Create a module object.
The name must be a string; the optional doc argument can have any type.

In [25]: class MyExtendedModule(module):
   ....:     def fff(self):
   ....:         print "ffff"
   ....:
In [27]: g = MyExtendedModule("new_module")
In [28]: g
Out[28]: <module 'new_module' (built-in)>
In [30]: sys.modules['my_new_module'] = g
In [31]: import my_new_module
In [32]: my_new_module.fff()
ffff

Для тех кто не силно знаком с питоном.
Имортировал модуль sys. Взял его класс, унаследовался от него,расширив
методом fff. Затем зарегистрировал экземпляр этого модуля.
А потом импортировал его-же стандартными средствами. 
А в перле так можно?

> Взял его класс, унаследовался от него,расширив методом fff.

А можно в Питоне переопределить или добавить метод без наследования? (просто интересно)

А как там в python с генерацией pdf ? reportlab ышшо не умер в конвульсиях ?

> А как там в python с генерацией pdf ? reportlab ышшо не умер в 
> конвульсиях 

Цветет и пахнет. Django с его помощью может вместо html pdf генерить.
http://www.reportlab.org/downloads.html.
http://www.reportlab.org/index.html

> А можно в Питоне переопределить или добавить метод без наследования? 

class X(object):
  def func(self,x):
    print "func"

y = X()
z = X()
y.func()
"func"
X.func = lambda self,x : "new_func"
y.func()
"new_func"
z.func = lambda x : "new_func2"
y.func()
"new_func"
z.func
"new_func2"

Нельзя без наследования переопределять методы у базовых 
языковых типов : str,list,dict,int,long,..

> Цветет и пахнет. Django с его помощью может вместо html pdf генерить. > http://www.reportlab.org/downloads.html. > http://www.reportlab.org/index.html

И что, они асилили уникод ?

>И что, они асилили уникод ?

Goals for the 2.x series

The main rationale for 2.0 was an incompatible change at the character level: to properly support Unicode input.

Вопрос к любителям перла.

Есть ли там следующие вещи: > Контроль доступа к атрибутам

Нет и не надо. На уровне "чтоб случайно не сломать" - есть в модулях.

> аналоги

[code skipped]

AUTOLOAD?

> Перегрузка операторов(+ - () [] ....).

Есть.

> Множественное наследование.

Есть, с несколькими вариантами method dispatch.

> properties

Есть в модулях. Есть function attributes, хотя ими почти никто не пользуется.

> Статические и классовые методы.

Класс - это модуль. Поэтому - да, в разных вариациях.

> Можно ли их использовать например с SOAP,CORBA,COM и сколько для етого придется кода написать?

COM - не знаю, это вражеская ненужная технология. SOAP must die, ибо убожестно (но есть, SOAP::Lite - _очень_ простой в использовании). CORBA есть "чуть-чуть" - я видел только для одного ORB.

> И что же там такое есть чего по ваш. мнению нет в питоне?

Свобода. Традиции. Наработки за четверть века.

> По пов. библиотек - AFAIK нет не только sci но и как уже сорок раз писалось,

> Wx,

Не знаю.

> Qt,

Есть, хотя и outdated. Gtk и Tk есть - живые и широко используемые.

> Pyro(OORPC),

Есть XML-RPC и SOAP в нескольких реализациях. Есть CORBA-биндинг (правда, для какого-то "непромышленного" ORB-а). Есть какие-то чиста-перловые RPC - но это все "не нужно".

> Django,Zope

Это веб-фреймворки, да? Catalyst, типа, рулид. Шаблонизаторов - море, и даже есть очень хорошие (TT2).

> SQLAlchemy(OORM)

Гораздо больше одной. Class::DBI, DBIx::Class, Rose::DB::Object. Все три весьма работоспособны.

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

> Свобода. Традиции. Наработки за четверть века.

С последним сложно поспорить, но как Вы понимаете масса наработок 
несколько устарела)). А свобода и традиции - ну так они и у чукчей
есть. Вопрос в том какие.

> Нет и не надо. На уровне "чтоб случайно не сломать" - есть в модулях.

Оно служит вовсе не для того что-бы поломать. С помощью него можно перехватывать обращения к атрибутам объекта для массы различных задач.
Например для имитации методов и полей, отложенной загрузки shared objects,отладки, логирования,.....

> Класс - это модуль. Поэтому - да, в разных вариациях

Т.е. все это было о эмуляции классов модулями? Т.е. один модуль - один класс - один экземпляр? Если я прав то к ООП это отношения не имеет.
Классы должен поддерживать инстанцирование (множественные экземпляры) иначе область прим. таких классов как у лямбды в питоне.
Она есть но тока для ф-ци в одну строку.

> Это веб-фреймворки, да? Catalyst, типа, рулид

Это не просто веб-фреймворки это полная интеграция БД,генерации страниц,удобной системы администрирования БД и еще вагона всего. 
Например django умеет вместо html генерить pdf,rest,txt,..
А zope предоставлять SOAP,FTP(и еще неск. вар) доступ к своей
ООБД, без написания Вами вообще никакого кода. Почему вокруг
рельсы стоко шума а? Так вот Django аналог рельсы с Админ интерфейсом.
У меня система катологизации CD/DVD дисков с поиском,добавление,редактированием,заметками,etc на Django влезла в 
500 строк из которых 200 - код сканирования файлов с обработкой а 130 
шаблоны.

Qt не просто outdated а последнее обновление больше трех лет назад.
> Gtk и Tk есть - живые и широко используемые.

Qt и они по возм. и документации(а значит по возможности применения в серьезных задачах) и ними даже сравнивать сложно.

> COM - не знаю, это вражеская ненужная технология
Эта "вражеская ненужная технология" - основа
форточки(и таковой еще долго будет оставаться)(и, кстати,
дающая в ней больше возможносте, чем родные и любимые програмные 
шины сообщений в линуксе) - а значит очень важна, если хочеш деньги зарабатывать. Потому как на то-же rentacoders без COM куча проектов сразу отпадает(это просто один пример).
Pyro и SOAP примерно как запорожец и мерс.

> Короче, питон не настолько лучше перла, чтобы переучиваться 
> (например, к питону не подходят мои навыки редактирования) и 
> переписывать гигабайты кода.

А никто и не предлагает :). Куча моих знакомых так на 
фортане77 пишут что им и нафик не нужно им больше ничего.

К языковым возм, кстати еще относятся замыкания(в т.ч. замыкания экземпляров), итераторы, сопроцедуры, list comprehension ,
функциональное программирование. Так таки получше ).

>> Цветет и пахнет. Django с его помощью может вместо html pdf генерить. http://www.reportlab.org/downloads.html. http://www.reportlab.org/index.html

> И что, они асилили уникод ?

Они осилили загрузку TTF шрифтов и UTF8. Лучше бы они осилили юникод, но ничего, вполне можно использовать.

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

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

Если этого ничего нет - значит все остальное легко зашивается в статику - получается утилита.

> синглтон может быть инициализирован определенными с определенными условиями: может отличаться реальный экземпляр класса или его параметры в зависимости от...(платформы, предпочтения разработчика, окружения и т.д.)

И модули всё это могут.

> А в перле так можно?

А почему бы и нет? Для следующего кода, "use strict; use warnings;" проставите сами. Как и присвоение к "@ISA" или "eval + use base;" для динамического добавления наследования.

$class = ref $object;
*{"${class}::new_method"} = sub { print "new_method is called\n" };
$object->new_method;

В отличии от Python, объектная модель в Perl (как и в Ruby) схожа с Smalltalk, то есть все классы наследуют от корневого класса (UNIVERSAL). Добавив метод в этот класс (например data_dumper), он будет автоматически доступен всем объектам. Единственное чего нет в Perl, так это однородности касательно базисных типов и пользовательских классов. Однако всё это решено в Perl6, да так, что Python и Ruby могут позавидовать. :-)

М-да, ну и дискуссия. Весьма меня позабавила, спасибо. Особенно следущие тезисы:

* Zope - web-framework * Perl и Python схожи по выразительным возможностям * объектная модель Perl схожа со SmallTalk * в Perl есть объектная модель :) * для Питона категорически важна перегрузка операторов (и еще что-то, извините, забыл) * имеет значение, писать фигурные скобочки или ставить переводы строк * в CPAN есть аналоги Django и Zope (а аналога MS Windows там нет? только за ненужностью, видимо ? как пригодится, сразу напишут) * отличный свободный синтаксис Perl позволяет писать красивые понятные программы

Замечу, что в дискуссии не разу не упоминался tooling и применение higher-order functions, и даже про метапрограммирование какой-то умный человек сказал лишь раз. В принципе, на этом можно было бы и закончить, но всё же.

Zope ? уникальная разработка, такая, как, например, Eclipse или EJB на Java. Язык можно (в смысле, что бывают такие случаи) использовать только из-за нее, а не из-за каких-то языковых особенностей. Штучным библиотекам редко бывают аналоги в других языках.

Django ? исключение, но Django я бы и не стал ставить в заслугу Питону, ибо он копирует Rails. Копия редко получается лучше. Пусть даже копирует он не 1:1, а с изменениями. (Что ожидаемо, Python и Ruby ? разные языки.) На PHP, например, есть Cake, и он тоже копирует Rails.

Perl, извините, не язык для ОО-разработок. Круг задач, решаемых без ОО, имеет известные границы. Здесь совершенно нечего обсуждать. (Даже если предположить, что в Perl есть ООП, то нет ни культуры его использования, ни адекватных библиотек, ни способных его применить людей. ООП, дорогие мои, это больше, чем классы и методы, это парадигма программирования, и в последнее время от неё ожидают достаточно многого в плане сложности решаемых задач, что без соответствующей поддержки языка обходиться не может.)

Я считаю Ruby более правильным языком, чем Python, ибо в нем есть SmallTalk'овские блоки. Python слишком часто копирует Java-подобные подходы. Впрочем, да, всё остальное в Ruby не так уж и важно. Можно жить без DSL'ей, и уж точно нужно жить без идиотской реализации многопоточности. Впрочем, в Ruby ещё и метапрограммирование сильнее, примерно за счет SmallTalk'овской модели сообщений вместо вызовов функций.

Я верю, что Python-сообщество более интеллектуальное, чем Ruby-сообщество, и у них есть прекрасные аннотации, хитрости с метаклассами (гм) и еще всякие другие хитрости. Если бы они взяли от Ruby блоки и сообщения, то получился бы отличный язык. Кажется, как минимум к блокам всё и идёт, если я правильно слежу за новостями. (Только не говорите, что lambda ? это блок.)

Опять же, ни с Perl, ни с PHP я бы сравнивать эти два языка не стал. PHP/Perl для совсем других классов задач и для людей другой квалификации. Нужно, чтобы хотя бы слова "управление сложностью" представляли для человека не пустой звук.

Возможно, еще какие-то мысли по вопросу я освещал в своем блоге, в частности, на http://andreyvit.blogspot.com/2006/10/php5-vs-pythonruby.html.

Андрей Таранцов.

> дискуссия позабавила: в Perl есть объектная модель :) [...] Perl, извините, не язык для ОО-разработок.

Ну, зачем же, уважаемый Андрей, так явно показывать своё незнание. :)

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

* generic programming (pure polymorphism)
* advanced OO (multiple inheritance, operator overloading, delegation, metaclassing, run-time redefinable classes)
* aspects
* unix integrated
* functional programming (higher-order + first-class functions, closures)
* preprocessing (redefinable syntax)
* metaprogramming

На Perl есть фреймворки намного интересней Zope (с точки зрения функциональности, лёгкости, гибкости и красоты). Правда многие из них непубличные (например я в своей компании за свои годы работы написал несколько фреймворков, положу на CPAN в следущем году). На Perl запросто писать GUI (как пример объекто-ориентированной задачи). Практически нет такой задачи, для которой Perl не подошёл бы (включая всевозможные плагины к будь то веб серверу, текстовому редактору, оконному менеджеру, и даже для игр и модулей ядра).

Советую не полениться и потратить несколько лет на углублённое изучение Perl. Тогда взгляд на Python может освежиться и расшириться. И кто знает, возможно Python покажется хорошим заменителем Visual Basic (тоже такой динамический ОО язык), но явно не тянущего на звание идеального языка программирования, а тянущего лишь на звание очень удовлетворительного.

Могу согласиться, что Ruby - отличный язык, но тоже блекнет рядом с возможностями Perl5 и Perl6. :-)