Exception #05. Бесплатный семинар по Python в Киеве.

lefsha, вы наркоман.

> в native код нельзя компилировать

С определенными ограничениями компилируется pyrex.

Научитесь понимать разницу между self в Boo и self в python. http://dpaste.com/11009/

Вот на такой конструкции в python построено многое. К примеру функция map в базовом namespace. Не сравнивайте языки с разной механикой. Функция myfunc изменит у объекта аттрибут. А функция str - не сможет потому что она ничего не знает о объекте.

Это программирование, разберитесь с учебником языка сначала - а потом пишите - это нужно, это не нужно. Понятия не имею как все обстоит в Boo - и не берусь судить и его синтаксисе. Зачем же вы судите о Python не зная как, что и почему работает?

Возможно это вы написали Zope, Twisted, SQLAlchemy, Django, Pylons? Если бы self был не нужен при определении функции-метода - от него бы отказались давным-давно. Опять же рекомендую - почитайте учебник, сначала. Если вы что-то не понимаете - это не значит, что это не правильно.

> ну если кроме self и def в питоне нет ничего стремного - то он тогда вобще впереди планеты всей :-D

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

>Причем тут С я так и не понял. Си тут при том - что вы меня спросили знаком ли я с ним. А вы знакомы с Python?

> Зачем писать то, что надо писать в любом случае?

Вместо self можно написать this. Или еще что-нибудь по вкусу.

> То что нельзя проверить программу на этапе компиляции.

Зато можно реализовать более сложное поведение.

> И потом это будет работать, только для маленьких проектов. Когда код легко объять глазами.

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

> ну как ты не понимаешь! Если ты в описании класса напишешь method = method то ты хуйню получишь, а не результат который имеешь ввиду. Благодаря self ты можешь включать какую-то логику при инициализации объекта, в зависимости от которой у объекта какие-то аттрибуты будут,а какие то нет. Без self у тебя нигде не определно будет что вот сейчас это просто переменная внутри нашей логики, а вот сейчас это аттрибут объекта.

Отличный комментарий! Он прекрасно свидетельствует во первых о том, что Питон имеет проблемы с областью видимости и что отсутствие описания переменных есть плохо.

Для справки. То что Вы хотите делать делается во всех нормальных языках без self. В нем просто нет смысла.

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

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

Поговорим когда вы прочитаете учебник для начинающих.

> Фирма мигрирует с зоопарка M$ на Линукс и Питон.

Фраза дня :)

Раз Вы не поняли вопроса, то так и надо говорить.

Вы путаете совершенно разные вещи.

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

Вы же начали показывать как неправильно стравнивать С и Питон...

Это бесммыслица. Или спор со своими собственными воображаемыми идями.

> То что Вы хотите делать делается во всех нормальных языках без self.

Опаньки! Оказывается, C++, C# и Java -- языки ненормальные?

> Вместо self можно написать this. Или еще что-нибудь по вкусу.

Можно. Только зачем? - А пока не можно, а обязательно к сожалению.

> Зато можно реализовать более сложное поведение.

Стремится следует к простому... А не к сложному.

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

Именно. В этом смысле он не далеко ушел от PHP. А жаль, мог бы вырасти в нечто большее..

> Напротив this в плюсах нужен именно чтобы получить указатель на сам объект изнутри,

Открою Вам страшную тайну: в Python self нужен в точности для того же. Сюрприз?

> но никак не чтобы добраться до его членов.

Угу. То есть, конструкции вида this->foo, оказывается, не нужны. Это ж надо, какой избыточный язык, этот C с крестами.

>Отличный комментарий! Он прекрасно свидетельствует во первых о том, что Питон имеет проблемы с областью видимости и что отсутствие описания переменных есть плохо.

>Для справки. То что Вы хотите делать делается во всех нормальных языках без self. В нем просто нет смысла.

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

Еще раз объясняю различие между функцией и методом только в наличии self. Функция может менять кучу объектов и быть присвоена как callable-атрибут к объекту. При вызове аттрибута - он не станет методом - а изменит те объекты которые в области видимости функции - а она может находится где угодно.

Если в функции вызывать self - это будет неопределенная переменная и без типа: self.var = 1 создаст ошибку. Python строгий язык.

Поэтому в метод и передается self - ссылка на этот самя объект "Я". Интерпретатор при вызове callable аттрибута проверяет - есть там self - и если есть отправляет в него по-умолчанию собственно объект, а если нет исполняет как обычную функцию. self.hCon.some = self.log создаст для объекта hConn новую функцию с форматированием логов в другой файл. Это позволяет делать вещи которые вы себе не можете представить даже.

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

Отвяжитесь от примитивного мышления и начните думать наконец не как - где-то удобно, а как думает человек программирующий на python. Я занимаюсь не размышлениями над тем нужен self или нет. Без него можно обходится - и по моему в ZopeInterface именно так дело и обстоит. Но если мне нужно привязать к объекту новый динамический метод или переопределить старый - я напишу функцию с def(self) и она будет знать кто ее "Я".

Откройте новую страницу в программировании. Увидьте мир по другому, а не со своей колокольни.

> Можно. Только зачем?

Для выразительности. Или мсье -- большой поклонник Брэйнфака?

> Стремится следует к простому... А не к сложному.

"Усложнять -- просто, упрощать -- сложно" (C)

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

> В этом смысле он не далеко ушел от PHP. А жаль, мог бы вырасти в нечто большее..

Если предположить, что это не 4.2, то Жаба тоже далеко не ушла от PHP. А жаль, она бы тоже могла вырасти в нечто большее :-).

А вообще открою Вам вторую страшную тайну: Python -- это такой недолисп (вы тока труъ питонистам и лисперам не говорите -- обидятся). Так что, с его родословной Вы тоже промахнулись...

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

http://www.pcmag.ru/solutions/detail.php?ID=6043

> Открою Вам страшную тайну: в Python self нужен в точности для того же. Сюрприз?

Нет. Вы неправы. В плюсах this совершенно не нужен там где используется self в Питоне.

> Угу. То есть, конструкции вида this->foo, оказывается, не нужны. Это ж надо, какой избыточный язык, этот C с крестами.

Еще раз. Из функции класса объекты класса доступны напрямую! this там не нужен! Он нужен только в функциях друзьях класса, где необходимо указывать параметр какого экземпляра в данному случае нужен. В частности часто используют его в переопределении операторов.

>Именно. В этом смысле он не далеко ушел от PHP. А жаль, мог бы вырасти в нечто большее..

Смеемся в голос. Python взрос на Zope. На python создаются проекты вростающие в язык и сживающиеся с ним.

> Стремится следует к простому... А не к сложному. А python и есть простое. Тут все настолько просто, что с вашими закостенелыми мышлениями средневекового варвара - сложно понять как все просто. В Python сложность в простоте. есть Def, есть class, есть self. Все - больше ничего нет и не надо.

И еще. В среде программирующих на python людей есть такая фраза - нравится программировать на perl - оставь нас в покое. Вот и вы - нравится Boo - Буукайте в сторону. Не надо читать статью на сайте Boo (for python programmers) про self и верить коммерческим понятиям. Разберитесь в механике языка. А потом занимайтесь сравнениями.

Вы не имеете представления о синтаксисе языка, а сравниваете его развитие c php. Сравниваете язык с Boo. Откройте сайт Boo и python.org сравните документацию по проектам. Я до сих пор пытаюсь сообразить, а где же на boo telnetlib? В python я быстро нашел Index Modules - а в Boo не могу. И это тоже сторона языка - комфорт в документации очень важен. Этим python отличается от всех - от php, perl, boo, ruby - кого угодно.

P.S. Нравится программировать на Boo - забудьте о существовании Python.

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

А мужики и не в курсе!..

>Еще раз. Из функции класса объекты класса доступны напрямую! this там не нужен! Он нужен только в функциях друзьях класса, где необходимо указывать параметр какого экземпляра в данному случае нужен. В частности часто используют его в переопределении операторов.

В python нет определения методов - поймёте вы это или нет? У объекта может не быть методов вообще.

class test:

pass

Вот и весь класс. А все методы будут привязываться к нему из других объектов. self - это указатель из C а не this из Си++. Если вам так будет понятно.

Выкиньте из вашей головы предубеждение наконец-то - вы просто уже смешны со своей претензией к self. Self нужен, чтобы определить ссылку внутри функции - ссылку на объект с которой его вызывали. И не только - он нужен еще кое-чего, но пока лучше вам об этом не знать-)

Ну, раз столько народа кормит тролля, чем я хуже? :)

> this там не нужен!

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

> http://www.pcmag.ru/solutions/detail.php?ID=6043

LOL. Статья феерическое говно. Сказочное.

"Общая информация приведена в таблице, отметим только, что за реализацию массивов и структур сняты баллы, поскольку вместо них необходимо использовать классы и списки, с булевского типа также снят балл, поскольку отсутствуют предопределенные константы false и true."

Вот жеж дятлы.

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

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

В частности автор Питона, этим отличается, иначе не было бы этой несовместимой версии 3000....

По крайней мере мне приятно, что он осознал сей факт. Хотя некоторые тут все советуют мне почитать учебник.

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

>А мужики и не в курсе!.. Угу. Сейчас пойду и яд выпью. В рекомендации по оформлению 4 пробела пишут зазря наверное. Видимо на разных платформах пробелы разные. Удавицо.

> http://www.pcmag.ru/solutions/detail.php?ID=6043

"Общая информация приведена в таблице, отметим только, что за реализацию массивов и структур сняты баллы, поскольку вместо них необходимо использовать классы и списки, с булевского типа также снят балл, поскольку отсутствуют предопределенные константы false и true."

Однако, автор обзора -- знатный специалист по Питону...

> Вот жеж дятлы.

Исчо перл:

"Как таковых модулей в Python нет"

LOL!

>Откройте новую страницу в программировании. Увидьте мир по другому, а не со своей колокольни.

Для всего вышеописанного _в декларации функции_ self _не нужен_.

> Не надо ничего никуда вбивать. Простая эволюция приведет к более оптимальному языку.

Угу. В Яве уже привела нах. 100000000 строк кода, чтобы описать три тонны классов-близнецов, которые можно было бы породить динамически.

> Мало того SomeMethod(self): вообще глупость. Ты кажется не понял, что SomeMethod - это у меня *просто* функция?

> То что нельзя проверить программу на этапе компиляции.

У меня прога на питоне читаем саму себя частично из внешних файлов и добавляет в себя код по хожу дела. Какая еще компиляция? Про использования питона в играх скажем как встроенного языка не слышал что ли?

> Проблема с run-time в том, что код не обязательно может дойти до данной точки выполнения.

Дядя, пойми же наконец, что прогу все равно надо тестировать полноценным unittest, который должен именно что пройти *все* точки выполнения, чтобу убедится, что там не ошибок. Вне зависимости от того, на питоне она или Анси С. И именно unittest в скриптовых языках у нас вместо проверки на этапе компиляции. Ну вылазь же из танка.

> Сэр никогда не видел С?Сэр никогда не видел С?

Вопросов более не имею. Ваш мозг, я опасаюсь, отчасти выеден C/C++/ и прочими языками со строгой типизацией, так что теперь вы будете требовать ее везде. Не нравится питон - используй С и не парься. Насильно заставлять писать на питоне никто не будет (пока).

> Для всего вышеописанного _в декларации функции_ self _не нужен_.

И эти люди рассказывают нам о религиозном фанатизме? 8-)

>А мужики и не в курсе!..

Очень зря. Если бы мужики подумали о кодогенерации мужики бы поняли что введение в структуру языка значимых отсупов - это hell on earth.

> с булевского типа также снят балл, поскольку отсутствуют предопределенные константы false и true.

Афтор не врет - ведь там нет констант true и false! А True и False - это совсем другие константы, понимаешь ли.

> Если бы мужики подумали о кодогенерации мужики бы поняли что введение в структуру языка значимых отсупов - это hell on earth.

А мужики подумали. И решили, что - нах ее. Хотите кодогенерацию - используйте лисп. Лучше чем там все равно нигде не получится.

> Если бы мужики подумали о кодогенерации

Какая нафик кодогенерация, если в Питоне программа сама себя изнутри строит? Это в Яве нужна кодогенерация, чтобы нагенерить те самые 100000000 строк кода для трех тонн классов близнецов, чтобы потом мужественно их скомпилировать.

PS. Ничего против Явы лично не имею. Фанатики могут подставить C# или C++ по вкусу.

> А мужики подумали. И решили, что - нах ее. Ога. Python-way однако-)) Нравицо как где-то в другом месте - идите в другое место.

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

> А мужики подумали. И решили, что - нах ее. Ога. Python-way однако-)) Нравицо как где-то в другом месте - идите в другое место.

Две пустые строки после квотинга. Две(2).

> Если бы мужики подумали о кодогенерации мужики бы поняли что введение в структуру языка значимых отсупов - это hell on earth.

А это не лечится написанием чуть более сложного кодогенератора?

>И эти люди рассказывают нам о религиозном фанатизме? 8-)

Посмотри как все тоже самое сделано в JavaScript.

>> Сэр никогда не видел С?Сэр никогда не видел С?

>Вопросов более не имею. Ваш мозг, я опасаюсь, отчасти выеден C/C++/ и прочими языками со строгой типизацией, так что теперь вы будете требовать ее везде. Не нравится питон - используй С и не парься. Насильно заставлять писать на питоне никто не будет (пока).

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

Тогда стоило ли спрашивать?

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

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

>Какая нафик кодогенерация, если в Питоне программа сама себя изнутри строит?

*хитренько так* значит eval в питоне не нужен? я правильно понял?

>Это в Яве нужна кодогенерация, чтобы нагенерить те самые 100000000 строк кода для трех тонн классов близнецов, чтобы потом мужественно их скомпилировать.

Ну и кто тут говорил о религиозном фанатизме, если ответ "в колбасе нужды нет"? Метапрограмминг не того - неосиливаем? Что трудно представить себе задачу когда приложение или некий его аспект строится из описания некой модели?

> Для всего вышеописанного _в декларации функции_ self _не нужен_.

Да, там можно написать и другое имя параметра %)

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

a = AnotherClass(); a.a = 2; print SomeMethod(a)

после этого?

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

А что - догадаться о том что философию "мой любимый язык fits all а что не fits не нужно" не разделяют все кому попало? И что первичным исходником модели может быть не питон? Между метапрограммированием и метаклассами связь весьма косвенная. Различного рода параметризация это мелкая часть метапрограммирования относящаяся к инструментам.

> *хитренько так* значит eval в питоне не нужен? я правильно понял?

Нужен. Да, генерить многострочный кусок внутри функции - облом. Ну так генери тогда новую функцию, что-ли.

> Что трудно представить себе задачу когда приложение или некий его аспект строится из описания некой модели?

Представить не сложно, spin видал.

Ну и строй код с отступами, там же чай не 3 строчки будет? %)

>А это не лечится написанием чуть более сложного кодогенератора?

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

> *хитренько так* значит eval в питоне не нужен? я правильно понял?

Нужен. Для крутизны и в особо извращенных случаях. Если понадобился eval, значит, плакать о трудных отступах уже поздно.

> Метапрограмминг не того - неосиливаем?

Метаклассы уже не устраивают?

> Что трудно представить себе задачу когда приложение или некий его аспект строится из описания некой модели?

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

Хотя, недавно подталкивали одно интересное решение -- когда парсер на C генерирует Python-код, который потом подается на вход интерпретатора. Однако, про отступы и тут никто не плакал. Видно, не такая уж и проблема... Лично я решил задачу путем написания биндинга к своему парсеру на C.

> А что - догадаться о том что философию "мой любимый язык fits all а что не fits не нужно" не разделяют все кому попало?

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

:-)

> Речь не о том пользоваться или нет. Речь о недостатках.

Это про типизацию? Учитывая eval - как мы будем вообще проверять обязательное описание переменных при *компиляции*. Ась? Может код с ее описание потом вставят. Как проверять поля класса, если они динамически добавляются по мере надобности? А если задача не требует ни eval, ни легкого динамических полей классов - ну так C# к вашим услугам, инструмент выбирают по задачам.

Наличие def недостатком не считаю, см. выше объяснение. Про селфм сотри мой ответ r, можешь мне объяснить мою ошибку, возможно я что-то не понимаю.

> Посмотри как все тоже самое сделано в JavaScript.

Я знаю, что JavaScript -- очень мощный язык. Настолько мощный, что использовать его самостоятельно практически не представляется возможным.

Как говорится, усердие все превозмогает...

> Геморой должен уменьшаться с развитием а не увеличиваться.

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