LINUX.ORG.RU

Python 2.2.2


0

0

This being a bug-fix release, there have been no exciting new features implemented since 2.2.1 -- just heaps of fixes.

With special dispensation from the "bugfixes only" rule, a brand new version of the email package (nee mimelib) is also included: email 2.4.3.

For a partial list of these fixes, please see the release notes, or the Misc/NEWS file in the source distribution. For the full list of changes, you can poke around CVS.

>>> release notes

★★★☆

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

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

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

anonymous
()

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

anonymous
()

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

anonymous
()

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

lg ★★
()

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

anonymous
()

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

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

lg ★★
()

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

PitStop
()

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

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

singerschucher
()

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

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

hbee ★★★★
()

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

MrKooll ★★★
()

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

lg ★★
()

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."

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

anonymous
()

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

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

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

anonymous
()

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

DonkeyHot ★★★★★
()

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()

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

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

anonymous
()

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

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

anonymous
()

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

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

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

DonkeyHot ★★★★★
()

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

anonymous
()

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

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

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

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

singerschucher
()

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'а, где жуткие зависимости между верясими иногда вылезают, и так далее и тому подобное. Да, за такую централизованость приходится платить. Но я считаю это разумной ценой ;-)

bormotov ★★★☆
() автор топика
Ответ на: комментарий от singerschucher


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

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

anonymous
()

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

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

dem ★★
()

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

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

anonymous
()

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

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

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

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

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

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

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

singerschucher
()

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

singerschucher
()

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

dem ★★
()

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

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

public void test(String param)
{
}

&&

public void test (Integer param)
{
}

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

i=1;

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

ifconfig
()

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

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

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

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

CybOrc
()

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

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


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

ifconfig
()

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

CybOrc
()

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

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

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

i=1

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

ifconfig
()

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

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

DonkeyHot ★★★★★
()

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

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

i=1 - тип int

CybOrc
()

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

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

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

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

кстати,
а что

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

??

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

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


>>i=1 - тип int

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




ifconfig
()

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

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

CybOrc
()

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

>> i=1 - тип int

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

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

badger
()
Ответ на: комментарий от CybOrc

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

anonymous
()

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

CybOrc
()

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

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

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

CybOrc
()

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

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

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

badger
()

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

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



ifconfig
()
Ответ на: комментарий от ifconfig

import types

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

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

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

anonymous
()

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

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

DonkeyHot ★★★★★
()

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

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

ifconfig
()

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

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

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

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

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

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

CybOrc
()
Ответ на: комментарий от ifconfig

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

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

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

DonkeyHot ★★★★★
()

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

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

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

тоесть

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.

ifconfig
()

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

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

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

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

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

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

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

CybOrc
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.