14 точно лучше оставить для половинок )

Сейчас меня больше всего заботят вопросы про 14

а 23 вполне норм же

Сейчас меня больше всего заботят вопросы про 14

14 все равно пока нет никого

14 все равно пока нет никого

И это тоже меня заботит

14 точно лучше оставить для половинок )

Перенесем на 16, четверг, тогда. Думаю, не должно быть проблем

а 23 вполне норм же

Выходной, праздник. Будет много народу, музыка громкая, вот это всё.

Выходной, праздник. Будет много народу, музыка громкая, вот это всё.

Вполне рациональным выглядит 22ое, хотя возможно там будет больше.

Перенесем на 16, четверг, тогда. Думаю, не должно быть проблем

Ооо хорош X)

Ооо хорош X)

А что?

Так это клуб 27 покидаю ?

Используем vim как Python IDE http://www.liuchengxu.org/posts/use-vim-as-a-python-ide/

Так это клуб 27 покидаю ?

Ты пьян? Я опять тебя не понял.

Др у меня 16го XD

Ну, извини. Локальная проблема. В любой день есть вероятность попасть на чей-то ДР.

Но ты сможешь передвинуть на более удобную тебе дату, если сделаешь доклад

Др у меня 16го XD

С днем рождения, кстати :3

Так рано еще, ты лучше 16 го притопывай

Справедливо, да.

Парни с юмором

так может это кот удалил базу

бедный чувак

я всегда переживаю за инициаторов таких историй

так может это кот удалил базу

Это он и есть, кмк

зато у него теперь есть готовый шикарный ответ на 'what's the story behind your biggest fuckup?'

https://vk.com/wall-60684683_2479

хорошая инициатива

странно что до сих пор не было такой. Или была?

это как день проверки работает ли у тебя авторизация на сайте

Интересно, что до сих пор существуют упоротые фанаты svn, у которых "всё работает не хуже, чем в git"

есть и не фанаты, просто бинарей дофига живут на виндах, а gitlargefiles пробовали, работал хреново

Интересно, что до сих пор существуют упоротые фанаты svn, у которых "всё работает не хуже, чем в git"

человеческая психика имеет спасительную способность к самозащите

Как говорил один товарищ: "Работа с SVN это боль и унижение"

Как говорил один товарищ: "Работа с SVN это боль и унижение"

Как-то не в рифму

Как-то не в рифму

Здесь нет поэзии, только боль и унижение...

я всегда переживаю за инициаторов таких историй

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

зато у него теперь есть готовый шикарный ответ на 'what's the story behind your biggest fuckup?'

Poor Yorik...

да вот я тоже думал как пошутить на тему шекспира

но потом бросил это занятие, рассудив, что уже умными людьми всё пошучено как следует

и мемы оформлены и подшиты в дело

Это у вас в датарт?

Это у вас в датарт?

Это у меня рядом с домом. Рядом с ДА тоже зал есть, но я там не был. Они даже какие-то льготные условия вроде предлагали.

доброе утро)

кто напомнит как прописывать параметрищованные метода объекта типа class A: def get_parsed_%FIELD%(self): return '...'

&

?

миетокласс:)

чую может быть проще через декораторы

А как это выглядит? :)

декоратор тебе результат положит в атрибут с тем же именем, вокруг которого ты его повесил

проще видимо геттер переопределить немного, метакласс покрасивее будет

проще видимо геттер переопределить немного, метакласс покрасивее будет

getattr. но это опасная игра.

А почему просто функцию не сделать?.. Зачем делать максимально непонятно? :)

их много с одинаковым методом парсинга?

А почему просто функцию не сделать?.. Зачем делать максимально непонятно? :)

а какую? идея в том, как я понимаю, что надо динамически создать метод с именем вычисляемым из имени другого атрибута, если атрибут удовлетворяет некоторым условиям

а какую? идея в том, как я понимаю, что надо динамически создать метод с именем вычисляемым из имени другого атрибута, если атрибут удовлетворяет некоторым условиям

да

Учитывая, что дали: class A: def get_parsed_%FIELD%(self): return '...' Я думал про: class A: def get_parsed(self, field_name): return self.do_something_with_the_field(field_name)

Просто … зачем :)

Зачем создавать именно функцию отдельную, если можно внутри функции нарулить то же поведение?

field_name строка - туда что угодно можно передать в данном случае

в IDE не видно будет что это параметр не атрибут класса

ERROR: S client not available

Мне кажется это меньшее зло :)

Зачем создавать именно функцию отдельную, если можно внутри функции нарулить то же поведение?

с этим я согласен:) но задача же про метод. надо наверное ;)

Чем нагородить implicit поведения.

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

А он вызывается же.

в IDE не видно будет что это параметр не атрибут класса

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

не понял о чем ты

мне тоже советовали сделать парсер функциями, а я сделал классами и доволен

@lig11 этот парсер у себя создает те самые get_… методы? В общем оно теми же проблемами линтинга будет обладать

только метакласс не поможет, если ты список параметров во время создания класса еще не знаешь. тогда только играться с getattr

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

+

вот почему-то мне казалось что в питоне это как раз стандартное поведение

мб перепутал с другим языком)

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

На то и клёвый динамизм)

стандартное. но если ты меняешь поведение в риалтайме, то надеяться, что IDE это поймет наивно

Клёвый динамизм не отменяет принцип "явное лучше неявного"

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

хочется всеобъемлющих линтеров — welcome to логическое программирование. coq, idris, вот это все. с доказательствами корректности кода и так далее

Клёвый динамизм не отменяет принцип "явное лучше неявного"

В питоне столько неявного что я не верю их этому принципу

Написать что-то, что работало бы без ошибок, с переопределением __getattr__ довольно сложно. А ещё сложнее будет сопровождать этот код.

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

В питоне столько неявного что я не верю их этому принципу

Если во всякие метаклассы не лезть, то всё достаточно явно. :) В 3 стало всё ещё более явно, когда добавили строгости.

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

Ну не rocket science, конечно, но требует должного внимания.

Ну, из последнего в двойке сравните генератор и список.

В 3 на <> подобное проверить уже не выйдет. А оператор == возвращает False, что вполне логично.

В 3 на <> подобное проверить уже не выйдет. А оператор == возвращает False, что вполне логично.

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

А принцип этот давно форсится.

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