Python отличная вещь. Я сначала познакомился с Zope и как следствие начал изучать Python.

Есть два вопроса: 1. Как правильно с точки зрения native English читается Zope? На zope-forum.org немцы сказали, что [zoap], но не были сильно уверены.

2. Кто-нибудь запустил у себя VisualPython(www.vpython.org) под FreeBSD? У меня Python слетает.

а вот, ежели постараться объективно, zope - вещь полезная? я что-то в ней ничего рульного не обнаружил...

имхо ооп у питона такой-же недоделанный, как и у перла. даром, что родной

2 last anonymous:
ооп вполне нормальный. Что тебя в нём так напрягло? может не разобрался в чём то?

2 lg:
Скорее всего так и есть :)
Остутствие приватных данных, например.

а мне больше нравиться писать:
iv = claS.int_val нежели iv = claS.get_int_val()
и claS.int_val = iv нежели claS.set_int_val(iv)

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

А почему новость не по русски?!! org.ru или не org.ru???

1) все в классе открыто по умолчанию
2) первый аргумент в методе - self

Это такое же Г как и ОО в Перле
Попробуйте Ruby, это настоящее OO

>Попробуйте Ruby, это настоящее OO

Присоединяюсь, мне Ruby тоже гораздо больше нравится, чем Python.

anonymous (*) (2002-10-15 11:59:08.324) Доки читать не пробовал? class MyClass: def __private_procedure(self):

ruby - руль! много питонистов любят эту мульку.
мне питоновского ОО вполне хватает - хотя я больше процедурщик и функциональщик нежели ООПешник .. :)

2 MrKooll:
Дык, пробовал. Как сейчас помню:

"Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private."

Так что это не более чем подпилка...

perl и python ставятся в любом дистрибутиве в обязательном порядке. Вот когда ruby дорастет до подобного уровня, тогда на него и можно будет посмотреть. А пока рановато ...

<<Ruby needs no variable declarations.>> -- только _реальный_долбень_ будет рад такой "фиче"

А если ОО в перле вам плох, так вы с ним разберитесь - после этого про плюсовое ОО вам будет тошно вспоминать.

А вам программы писать, или концепциями OO баловаться? С точки зрения писания программ отсутствие ограничений на доступность переменных может помешать при крайне неаккуратном программировании - а если и подпорка в виде "__" недостаточна для избежания ошибок -- наверное вы злобствующий программер, пытающийся развалить проект, в котором участвуете :-) То есть конечно __ некрасиво но вполне достаточно. self первым аргументом тоже не сильно приятен, но (AFAIR) не сильно лучше чем в Ruby - там вроде нужно писать какой-то знак $|@|еще какой-то. Что для ленивого программиста - те же 2 кнопки (если self назвать например s - "s." вводится теми же 2мя нажатиями :-) Хотя тоже слегка некрасиво, оверхед такой же(за исключением 2х символов в определении имени функции.

Анониму, любящему обьявлять переменные

Переложим работу компилера на пальцы программеров !!!
:-)

лично мне плюсы вообще тошно вспоминать, но это так, к слову. а с перловым ОО лично я разбирался. ну, как всегда в перле -- костыль на костыле. сделали "шоб було", для галки в основном. да речь, собственно, не только о том, где ОО лучше. просто питон по жизни гораздо удобнее перла и лучше продуман. давай все-таки помимо ОО мультитредовость вспомним, удобства расширения, терпимость к ошибкам. и кстати, по поводу всяких руби и перлов в сравнении с питоном, вот: http://www.mindview.net/Etc/FAQ.html#Ruby довольно здравое мнение

> Переложим работу компилера на пальцы программеров !!!

Объявить переменную - это работа не для компилера. К тому же эта "работа" настолько мала, что желание избежать её вызывает только удивление. Подобные "фичи" стоили слишком много крови еще фортрановским программерам, так нет, все еще находятся энтузиасты ...

> вот: http://www.mindview.net/Etc/FAQ.html#Ruby довольно здравое

Интересно, а сам Bruce Eckel программы пишет, или только книги о программировании? :) Мне вот кажется, что теоретики программирования и практики часто имеют различные мнения именно потому, что смотрят на вопрос с совершенно разных позиций. При этом каждый по-своему прав. Так что не надо увлекаться идейным радикализмом, а то дойдем до уровня Антихриста - типа расстрелять всех, кто был зачат папой-мамой не в канонической позе.

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

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

А насчет крови програмистов - пишите на правильных языках :-)

2DonkeyHot (*) (2002-10-15 19:40:55.006)
что за бред ты несешь!!!! явное объявление переменной как минимум для того, чтобы если ты напишешь if ( function ( str1, x, y ) ) { } вместо if ( function ( str2, x, y ) ) { }, то тебе компилятор скажет, что такая-то переменная не определена, а ебаные "умные языки (компиляторы, интерпритаторы)" съедят такую ошибку за милую душу. Найти такую ошибку потом будет очень сложно.

2 anonymous (*) (2002-10-15 17:30:46.243)

>perl и python ставятся в любом дистрибутиве в обязательном порядке. Вот когда
>ruby дорастет до подобного уровня, тогда на него и можно будет посмотреть. А
>пока рановато ...

А ты из тех, что позволяют дистрибутиву ставит пакеты за тебя?
Нет, ты из тех, что в свое время говорили, что Линукс использовать рановато, вот когда его начнет поддерживать Sun...

Словом, сиди у моря, жди погоды

2anonymous (*) (2002-10-15 10:50:25.184):

на самом деле, ZOPE - это акроним. Z Object Publishing Env. как такое обычно произносят? ;-))

заходит в http://zope.net.ru/About/mail-list/ там тебе все расскажут. Дла начала можно порыться в архиве, это обсуждалось на заре мейллиста

2anonymous (*) (2002-10-15 11:01:21.347):

полезная, но нужно уметь извлекать пользу. Идеи там хооршие, но как-то "непродумано концептуально"

2PitStop (*) (2002-10-15 12:44:34.614): а что там переводить-то? 10 слов? ну поленился я, спать уже собирался идти ;)

2anonymous (*) (2002-10-15 11:59:08.324): про приватные данные где-то есть в заметках GvR. Что-то типа "незачем прятять код о своего напарника". Мне этого объяснения хватило. Помогла некоторая практика, которую поимел с java, когда автор либы что-то поместит в приватные данные, и ты хоть тресни, ни засабкласишь, и через интерфейс не доберешься...

2anonymous (*) (2002-10-15 22:11:58.187): import unittest; print unittest.__doc__

Вера во всевидящий компилер, это хорошо. Я даже навскидку могу назваьт Eiffel. Только питон тут "немного не из той области". Ибо типы ДИНАМИЧЕСКИЕ. Ибо ВСЕ ДИНАМИЧЕСКОЕ. В этом кайф. Хочешь чтоб компилер "все ловил" - пользуй другой инструмент.

2люибетли ruby: лично мне ruby не нравится только тем, что он без батареек. Т.е. практически по каждому чиху нужно или самому писать либу, или искать долго и нудно. В питоне 80% нужных вещей в stdlib, out-of-box. И притяно то, что stdlib стараются поддерживать в хорошем состоянии, например в отличии от перлового CPAN'а, где жуткие зависимости между верясими иногда вылезают, и так далее и тому подобное. Да, за такую централизованость приходится платить. Но я считаю это разумной ценой ;-)

> А ты из тех, что позволяют дистрибутиву ставит пакеты за тебя?

Я из тех, кто выбирает пакеты, которые потом поставятся инсталлятором с добавлением необходимых по зависимостям. А ты значит из тех кто все ставит сам? Ну-ну, бешеной собаке полста верст не крюк. То-то тебе подумать некогда - все ставишь и ставишь, труженик бля.

Ну что вы сравниваете Py с перлом. Это разные вещи. Посмотрите что сделано на питоне и на перле. Это разный порядок. На перле только утилитки в основном и цги. А на питоне и корбавский брокер и Зоп и вон среда разработки от создателей Python Imaging - посмотрите на нее. Это просто шедевр.

Кстати и Гвидо и Ларри отдают должное метзу (это Ruby создатель) и сами пишут что этот чел сделал больше них. Но Руби пока сырой. У меня вылетал в корку раз 5 при тестировании самплов. Плюс много тут японский знает??? А почти все либы сопровождаются японцами и английская документация минимальна (В стиле учите японский и читайте вот этот реадми).

2 dem:
а на перле есть такая в ещь как WebGUI - имхо зопу не уступает :)

2 bormotov:
от напарника прятать может и не нужно, но нафига тогда это называть ООП?

2 anonymous (*) (2002-10-16 06:29:29.556)

> Я из тех, кто выбирает пакеты, которые потом поставятся инсталлятором с
> добавлением необходимых по зависимостям. А ты значит из тех кто все ставит
> сам? Ну-ну, бешеной собаке полста верст не крюк. То-то тебе подумать некогда -
> все ставишь и ставишь, труженик бля.

Ruby уже сто лет есть в нормальных дистрибутивах. Так что это проблемы твои и твоего дистрибутива.

2 dem
> У меня вылетал в корку раз 5 при тестировании самплов.

Удивительно. Мы используем Ruby в нашей конторе и ничего никуда не вылетает.
Может, проблема в другом?

2 bormotov
> практически по каждому чиху нужно или самому писать либу,
> или искать долго и нудно.

Не надо ничего искать долго и нудно - есть одно место, где все
собрано вместе - Ruby Application Archive

2 dem Не "метз" (ужас какой), а "мац" - matz, Yikihiro Matsumoto, Йикихиро Мацумото

2singerschucher За что купил за то и продаю. Может в стиле filez читал?

>>Работа компилера - определить, что программер захотел переменную,

Може я чего не понимаю, но если говориь об ООП, то как вы без определения переменных напишите полиморфные функции? что то типа такого:

public void test(String param)
{
}

&&

public void test (Integer param)
{
}

вопрос второй, как компилер определит тип переменной,
написав что-то типа

i=1;

P.S. Пользуйтесь нормальными IDE и эта работа не сильно утрудит ваши пальцы.

На самом деле меня тоже несколько напрягает отсутствие объявлений переменных...

use strict в Перле мне неоднократно облегчал жизнь. Для Питона бы что-то подобное...

> Може я чего не понимаю, но если говориь об ООП, то как вы без > определения переменных напишите полиморфные функции? что то типа > такого:

Можно, причем не сложнее, чем твой пример. В Питоне, в отличие от Перла, переменные имеют тип (только могут менять его в процессе выполнения). Функция isinstance спасет отца русской демократии. Да и в Перле часто можно определить тип переменной ref'ом либо регекспом. По поводу крывости определения типа переменной регекспом можете не говорить. :)

>>Можно, причем не сложнее, чем твой пример.

Можно помедленее, тоесть конкретно кусок кода, тогда мы сможем сравнить, что больше напрянает пальцы программера %)


P.S. питоном некогда не интересовался, но вот отсутсвие объявления пременных заинтересовало в теоритическом плане.

def test(param):
    if isinstance(param, int):
        ...
    elif isinstance(param, str):
        ...
    else:
        raise TypeError

чего-то не заметил укорачивания кода..
все теже указания типов переменной (только внутри) да еще и противные
условия (if, else) появились, применение которых без крайней необходимости в ООП вообще не рекомендуется...

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

да и еще , что никто на второй пример не отреагировал

i=1

к какому типу приведет ее компилятор?
1) integer
2) long
3) float
4).....

>то как вы без определения переменных
Ну естественно в С++ без определения переменных ничего не напишешь:-) Но в
"classname var; ...; var=SOME_EXPRESSION"
^^^^^^^^^^^^^^
эта вот часть лишняя - тип "var" определяется по типу "SOME_EXPRESSION". Так какой смысл ее писать?

>что-то типа i=1;
создает проблемы только потому, что разбалованые гуманоиды ленятся указывать с какими числами они собираются работать:). И эти проблемы решаются довольно просто если все численные типы могут быть приведены к какому-либо одному или указанием умолчательного типа чисел(как в перловом use integer).

"противность" субъективна

И чем тебе "if" не нравится?

i=1 - тип int

>>тип "var" определяется по типу "SOME_EXPRESSION". Так какой смысл ее писать?

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

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

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

кстати,
а что

float i = 1;
менее читабельно чем
i = 1.0

??

>>И чем тебе "if" не нравится?
ой... эта долгая песня, и перворачивать все свои мысли по этому поводу очень долго. Надеюсь про goto вы вкурсе?
Вкратце, код содержащий много if/else/switch
очень гиморно подерживать дальше, тоесть подобные конструкции сильно зависят от контекста объекта. В идеале, в ООП если вы производите модификацию одного класса(объекта) это не должно отражаться на других. В случае if это очень сложно. Порой невозможно.
в очень многих случаях можно обойтись бех if путем грамотного наследования и перегрузки методов. В этом случаее изменяя объект вы не думаете над тем , что происходит в его наследниках..

Хотя совсем обойтись без if/else кнечно пока неззя, но и появления оных в масовых количествах есть признак "дурного" тона.


>>i=1 - тип int

а почему не long у примеру?

Для данного конкретного случая if ничем не хуже перегруженной функции. Мне кажется, что так даже читабельнее. Так что это все субъективно.

Потому что long --- это 1L :)

2ifconfig (*) (2002-10-17 13:52:34.797):

>> i=1 - тип int

> а почему не long у примеру?

Да без разницы, какой тип получится в данном случае.
Пример совершенно некорреткный. Бессмысленно рассматривать тип
переменной без использования оной. ;-)

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

badger, вопрос корректный :) Переменная i получает тип после присваивания

> В данном случае if напрочь убивает полиморфизм. А значит при любом
> изменении в иерархии классов надо будет искать и править все эти
> чудовищные switch-подобные конструкции.Вообще, появление такого кода -
> есть недостаток проектирования.

Ну, не при любом. Более того, я навскидку не придумал примера, где нужно было бы править такие if'ы и не нужно было бы править объявление перегруженной функции. Может, кто-то приведет?

У if'а большое достоинство: он весь находится в одном месте, в то время, как разные перегруженные функции могут быть раскиданы по коду и быть даже в разных файлах. Читабельность у if'а лучше, другими словами, что немаловажно при работе в группе над большим проектом.

2CybOrc (*) (2002-10-17 14:21:57.809):

> badger, вопрос корректный :) Переменная i получает тип после
> присваивания

Согласен, вопрос корректный. Это я сегодня некорректный ;-)

>>Потому что long --- это 1L :)
тоже самое объявление только вид сбоку..

простейший пример замены if перегрузкой написали я и ты уже вверху %)
когда в зависимости от типа переменной выпоняеться разный код.

import types

class TestClass:
  def Myfunctions(self, TvoyParameter):
    if type(TvoyParameter) is types.StringType:
       # тут чего-то про обработку строк

    if type(TvoyParameter) is types.IntegerType):
       # тут чего-то про обработку целых...

а вот функции с одинаковыми именами
но разным кол-вом параметров будут
обрабатываться автоматически...

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

>компилер еще не научился читить мысли програмера
Опять же хаскель(нравится он мне:) может работать без явного задания типов переменных и параметров - он их вычисляет.

>>Читабельность у if'а лучше, другими словами, что немаловажно при работе в группе над большим проектом.

оччень спорное заявление.. Более того, большинство так не думают %) особенно что касаеться имеено больших проектов.

> тоже самое объявление только вид сбоку..

Не совсем. Перловый long - это не C-шный. :)

> простейший пример замены if перегрузкой написали я и ты уже вверху %) > когда в зависимости от типа переменной выпоняеться разный код.

Да, замена есть, но я не вижу, чем она лучше при смене иерархии классов. Ведь речь шла о том, что в случае смены иерархии с if'ом будут проблемы. Я не вижу причин, почему этих же проблем не будет с перегрузкой функции. :)

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

Может, лучше не будем говорить о большинстве? :) В данном случае большинство будет только по той причине, что проектов на C++ больше, чем проектов на Питоне. :)

>>тип "var" определяется по типу "SOME_EXPRESSION". Так какой смысл ее писать?
>читабельность кода даже самим разработчиком после недели его написания

Тип обьекта( с точки зрения читаемости программы) определяется не тем, что написано в обьявлении, а тем, как обьект используется. То есть если в данном месте я использую только ".toString" - мне абсолютно пофиг, передают ли мне Int ,Float,List или что-либо еще. А описание "MotherOfAllClasses var;" читаемости не прибавит.

Посмотрите на те же темплейты в C++. Описание типов там абстрактное. И при описании переменных указание типа переменной ничего не говорит о классовой принадлежности переменной(AFAIR). Только ее использование что-то скажет.

>>чем она лучше при смене иерархии классов.

очень просто....

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

тоесть

class A
{
public String test(String param)
{
return "test1";
}
}

class B extends A
{
}

class C extends B
{
public C()
{
someMethod(test());
}

public void someMethod(String param)
{
//что то делаем
}

}

тоесть это будет работать если даже в один прекрасный момент ты вздумаешь переписать в А метод test() с другим типом значения ( к примеру int) .. заодно в B напишешь что с ним надобно делать, и все это унаследуют.

class B extends A
{
public void someMethod(int param)
{
//что то делаем
}
}


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

class C extends B
{
public void someMethod
{
if(test() == "someString")
{
}
}
}


куда тебе пошлет тебя твой компилер если переписав метод test() c другим типом возврашаемого значения??? а теперь учти, что классов похожих на С у тебя в большом проекте сотни.. и в каждом нужно будет править твои if.

Ммм... А при чем тут функции с разными типами принимающих значений? К тому же, пример был написан не для Питона, и, мне кажется, к делу никак не относится.

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

Первый случай (путь C++): переписываем реализации функций для каждого множества типов аргументов

int f(int x) {...}
int f(float x) {}

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

Чем второй путь хуже первого?

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