>Поэтому я просто буду отвечать тут на разные вопрос про python

Это правда, что его придумали душевнобольные люди? Почему они сделали разделителем количество сраных пробелов?!!11одинодин
Даже obfuscated by design perl по сравнению с ним - легкочитаемая поэма.

>Даже obfuscated by design perl по сравнению с ним - легкочитаемая поэма.

Ну что я могу сказать... ничего хорошего на самом деле. Вообще на питоне можно писать адовый быдлокод. В худших традициях бангалора. Но это так фактически на любом языке. При правильном стиле он выглядит вполне себе вменяемо. И вообще ко всему в конце концов привыкаешь. Так что конкретизируй то что тебе не нравится.

С пробелами проблем лично для меня нет. Для своих нужд давно уже написал скрипт, меняющий шаг отступа либо заменяющий его на табуляцию.

Как вы умудряетесь жить с динамической типизацией?

>>8117

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

В первых главах dive into python есть пример очень удобного хэлпера, выводящего метаинформацию об объекте, классе, функции, ежели таковая имеется. В ряде случаев он позволяет начать ваять в репле, вообще не подглядывая в веб\тексовые доки.

>>8118
> Особенно там где вернуть могут фигпоймичто и в документации об этом ни слова.
Хм, я вот у себя в другом языке без строгой типизации пишу классы таким образом, что они работают с данными, тип которых заранее определён в списке переменных класса. Иными словами, методы в большинстве своём ничего не возвращают (а если возвращают, то это коротенькая помогашка 3-й/4-й ступени).

>>8120

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

Ты сломал мой мозг. Как ты определяешь типы в языке без строгой типизации, причем через переменные класса? я догадываюсь о чем ты, но формулировка все-равно срывает крышу

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

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

>>8124
Всё просто:
public $var = array();
public $var1 = '';
private $var2 = 0;
Страницу с описанием разметки опять не нашёл, так что плейнтекст.

> имелись ввиду всякие фабрики, возвращающие объекты непоймикакого класса, которым нужно скармливать генератор, которому передается какой-то непонятных данных кусок
AW SHIT, теперь я ничего не понимат. Зачем так делать?

>>8120
> переменных класса
Это поля класса так названы?

>Иными словами, методы в большинстве своём ничего не возвращают
Архитектура построена на методах, меняющих внутреннее состояние объектов? Это отвратительный подход в духе ООП.

>>8126

>Зачем так делать?

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

def make_worker():
__while True:
____data = yield some
____result = process(data)
____if not condition(result): break

some_fabric.getTaskInstance().run(make_worker())


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

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

>>8131
> Это поля класса так названы?
Да.
> Архитектура построена на методах, меняющих внутреннее состояние объектов?
Нет, на классах.
> Это отвратительный подход в духе ООП.
У тебя есть предложения получше?

>>8132
ЯННП

>>8137

>ЯННП

Индусы из бангалора смотрят на тебя с презрением.

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

>>8141
> Да что угодно лучше
Ты вруша и не способен на конструктивную критику, следовательно не нужен.

>>8142

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

Конструктивная критика? Такого подхода? Вот даже не знаю что сказать.
Когда я только только узнавал что такое С++ и конечные автоматы, мой код был наверное похож на то о чем говоришь ты - пачка внутренних состояний и методов вроде checkStateAndDoSomeShitWithIt(some_data_blob). Признаться, этот код был ощутимо лучше чем наблюдаемый у однокурсников бардак ввиду того что я хотя бы выделял состояния, по которым можно было отследить общую логику приложений и даже, при желании, составить граф вызовов, для чего правда требовалось приложить усилия ввиду общей макаронности такого подхода. Но он был плохо. Объективно плохо.

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

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

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

>>8144
> аналог большого блоба глобальных переменных
Объясни сначала, как глобальные переменные связаны с бинарником, если я не пишу программу на руби, которая выполняет программу на хаскеле, которая…
> на то о чем говоришь ты - пачка внутренних состояний и методов вроде checkStateAndDoSomeShitWithIt(some_data_blob).
Но я ничего такого не говорил. У меня и в методы не передаётся ничего, каждый основной метод сам знает, с чем он оперирует и куда кладёт результат.
> ввиду того что я хотя бы выделял состояния, по которым можно было отследить общую логику приложений
То, что я пишу для веба, полностью линейно и я рад тому, что это можно сделать линейно.
> Зачем выдумывать структуру данных есть можно впихнуть все внутрь блоба, ведь все равно все вызовы привязаны к нему?
Тред плавно скатился в обсуждение С++? А как насчёт некомпилируемых языков?
> Зачем заниматься какой-то архитектурой ради возможности использования куска кода в дальнейшем если этого добора кусок буду использовать только я, здесь, и сейчас?
В большинстве случаев лучше продумать и заложить зачатки функционала заранее, чем потом править больше, чем надо при рефакторинге.
>Зачем создавать какую-то структуру данных и тратить память на лишние ссылки если у нас уже есть один большой объект, который все используют?
В самом деле.

>>8142
> не способен на конструктивную критику
Мне казалось, картинка со штангой должна была намекнуть на определённую парадигму. Я не призываю к её использованию, но в любом случае избавление от побочных эффектов упрощает отладку, делает логику более прозрачной и уменьшает связанность кода.
Твой подход фактически полностью состоит из побочных эффектов.

>>8145

>Но я ничего такого не говорил.

Ну пусть будет some_data_blob.checkStateAndDoSomeShitWithIt(), разницы то никакой нет если бы я написал this вместо some_data_blob, ты бы понял сразу?

>Тред плавно скатился в обсуждение С++?

Нет. Сказанное мной универсально для любого языка.

>В большинстве случаев лучше продумать и заложить зачатки функционала заранее, чем потом править больше, чем надо при рефакторинге.

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

>То, что я пишу для веба, полностью линейно и я рад тому, что это можно сделать линейно.
>для веба

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

>>8146

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

>>8148
Мне казалось, что в среде программистов этот мем очень распространён.

Анонсированный ранее минигайд в читаемом виде: http://paste.lisp.org/+2VEB

Чтобы не потерялось:


Для начала небольшое напоминание о том что есть объект-итератор (честно спизжено отсюда - http://stackoverflow.com/questions/19151/build-a-basic-python-iterator )


>>> class Counter:
... def __init__(self,low,high):
... self.current = low
... self.high = high
... def __iter__(self):
... return self
... def next(self):
... if self.current >self.high:
... raise StopIteration
... else:
... self.current +=1
... return self.current - 1
...
>>> [c for c in Counter(3,8)]
[3, 4, 5, 6, 7, 8]
>>> [c for c in Counter(3,8)]
[3, 4, 5, 6, 7, 8]
>>> i = Counter(3,8)
>>> [c for c in i]
[3, 4, 5, 6, 7, 8]
>>> [c for c in i]
[]
>>> (c for c in Counter(3,8)) # хитрый синтаксис для создания генераторов
<generator object <genexpr> at 0x7fac32f85460>
>>> [x for x in (c for c in Counter(3,8))] # а теперь обратно в список
[3, 4, 5, 6, 7, 8]


По сути итератор - это объект с методом next(), который возвращает очередное значение и бросает StopIteration когда возвращать больше нечего. Такой объект можно дергать вручную, можно передать в for ( как обычный так и списковый из примера выше )

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


>>> def getCounter(low,high):
... current = low
... while current <= high:
... yield current
... current = current + 1
...
>>> getCounter(3,8)
<generator object getCounter at 0x7fac32f854b0>
>>> [x for x in getCounter(3,8)]
[3, 4, 5, 6, 7, 8]
>>> getCounter(3,8).next()
3


Как видим, мы создали функцию, которая возвращает объект-генератор, который является итератором(удовлетворяет интерфейсу?) и может быть дернут как через for так и вручную.

Самое интересное - то что происходит при вызове yield. Последовательное выполнение генератора прерывается и поток управления переходит к месту вызова метода next() генератора, возвращая значение, которое передано в yield-оператор.


>>> def genT():
... print "in generator!"
... yield 10
... print "second one"
... yield 20
...
>>> g = genT()
>>> g .next()
in generator!
10
>>> g .next()
second one
20
>>> g .next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>> g .next()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration


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


>>> def genGuessNum(n):
... str = "init guesser"
... while True:
... t = yield str
... if n==t:
... yield "bingo!"
... break
... else: str = "not this number,try again!"
...
>>> g = genGuessNum(3)
>>> g.next()
'init guesser'
>>> g.send(1)
'not this number,try again!'
>>> g.send(2)
'not this number,try again!'
>>> g.send(10)
'not this number,try again!'
>>> g.send(3)
'bingo!'
>>> g.send(3)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>> g.send(100)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
StopIteration
>>> g.next(100)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: expected 0 arguments, got 1

>>8147
> some_data_blob.checkStateAndDoSomeShitWithIt(),
Опять не то.
> Сказанное мной универсально для любого языка.
Сказанное тобой сложно понять. Ты даже слово блоб употребляешь в каком-то весьма узком известном тебе смысле.
> странно это слышать от человека, исповедующего указанный тобой стиль программирования.
Давно на организации класса сошёлся весь стиль программирования?
> Так и знал что хоть сколько-нибудь развитой логики у тебя нет
А она там нужна, телепат со стажем?

>>8153

Всегда считал что нижеследующее определение антипаттерна вполне себе общеизвестное и общепринятое.
http://insidecpp.ru/antipatterns/blob/

>Сказанное тобой сложно понять.

Плохо быть тобой.

>Давно на организации класса сошёлся весь стиль программирования?

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

>А она там нужна, телепат со стажем?

Так про то и речь же.

#!/usr/bin/env perl
use strict;

sub test {
my $variable = "value";
$variab1e = "another value";
}

print "It works!"

Global symbol "$variab1e" requires explicit package name at ./file.pl line 6.

#!/usr/bin/env python

def test():
variable = "value"
variab1e = "another value"

print "It works!"

It works!

Есть ли разумные решения этого для питона?

>>8155

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

test.py:4: SyntaxWarning: name 'varname' is assigned to before global declaration

Способ создания статических переменных для класса можно подсмотреть в примере создания синглтона через __new__

>>8156

Проблема в том, что питон проглатывает любые имена, не вызывая ошибок или предупреждений при компиляции (а то и не вызывая их вообще, в случае с присваиванием).

>>8157

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

>>8158

>По дизайну языка если ты присваиваешь значение переменной, которой нет в контексте - создается новая переменная. Мудачество это или нет - вопрос десятый.

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

>>8160

Нормально работают же. Как-то проблем это лично мне не создает. Не понимаю суть твоих опасений если честно. Приведи пример что-ли какой-нибудь.

>>8161

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

>>8162

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

Начал тут себе писать аватаркогенератор. Разрабач, подскажи каких-нибудь идей.

>>8159
>лисперы-функциональщики ликуют
Я думаю даже распоследнюю скобкоблядь нисколечко не ебет состояние дел в пыхоплеяде.

>>8164
http://softwaremaniacs.org/blog/2007/03/28/openid-mutants/

Типа такой ебатушки?

>>8154
> Всегда считал что нижеследующее определение антипаттерна вполне себе общеизвестное и общепринятое.
Ну для крестолюба может быть. Но кто тебе сказал, что я пытаюсь всё запихнуть в один класс? Если тебя интересует, то у меня порядка восьми моделек, цепляющихся к одному глобальному инстансу. Вот лишь бы говном полить, рюске погромисты.

>>8167

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

>>8165

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

>>8166

Лолнесовсем. Я хотел сделать попроще, что-нибудь вроде композиции из базовой картинки, меняющегося объекта рядом и небольшого текста снизу например Сырна с fgsfds, над пальцем которой можно вставлять рандомный пикчи кусок
Хотя такая идея как в той статье тоже интересная. Спасибо за наводку.

>>8168
> Я прощу тебя
ЧСВ своё за пояс заткни, ок?
> если для каждой модельки у тебя есть интерфейс взаимодействия с инстансом.
Есть. Про MVC слышал?

>>8169

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

>Есть

Прощен :3

>>8171
> В твоем изложении архитектуры
Найди мне в >>8120 слово «архитектура». Речь шла об удобстве использования методов отдельно взятого класса. Контроллер в конечном счёте использует некие данные, и берёт их из переменной класса. А метод, который может многократно вызываться в течение обработки, для каждой задачи использует одни и те же переменные класса в качестве входных данных и контейнера результата — отсюда понятность (3, а не 33 переменные), легковстраиваемость (задал исходные, вызвал и получил результат) и минимальный набор того, что нужно помнить при обращении (никаких лишних параметров методу, ненужных аннотаций и пояснений).

Да, я использую термин «переменные класса» потому, что ничего кроме как переменной эти переменные не представляют. «Полем» в моём представлении она становится, когда обрастает всякими геттерами, сеттерами или же становится объектом (или является им по умолчанию где-нибудь в других языках или фреймворках).

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

>>8173

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

>>8175
> Давай сойдемся на том что пихать все данные в один большой класс бесспорное зло.
Давай ты прекратишь талдычить про свои блобы и проецировать своё нездоровое восприятие окружающего мира на всё, что видишь, ок?

>>8176

Просто уходи. Не разговаривай со мной. Не пиши в этот тред. Занимайся в своем php или что там у тебя чем хочешь. Только не здесь. Хорошо?

>>8181
Пока-пока!

Подучи артикли на досуге перед тем как соберёшься постить свои аватарки в приличном обществе, ладно?

>>8183

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

>>8184
Это Сорк что ли фхтагнулся?