FishHook
Ну-ка объясни дяде.

AlekseyPython
Это вы к своей жене так обращайтесь.

Дядя? К жене? Экий ты затейник.

AlekseyPython
Вот что думают другие программисты про ‘self.’:

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

Если уж хотите чегонить нарыть гуглите “python self hell”, но в общем там в выдаче три или четыре ссылки действительно по теме, а остальное просто про self. Лично мне это всегда казалось удобным так как никогда не перепутаешь что являеться членом класса а что нет. Да и достаточно часто self приходиться предавать как аргумент еще куданить, может поэтому всех все утраивает, и проблема не кажется столь актуальной?
НОе если у вас совем уж подгорает , можете посмотреть презентацию Armin Ronacher “5 years of bad ideas”, там есть такой пункт как неявный self: https://speakerdeck.com/mitsuhiko/5-years-of-bad-ideas?slide=58

или вот еще такое “решение” http://code.activestate.com/recipes/362305-making-self-implicit-in-objects/
написано для 2-го пайтона, на третьем походу не работает, но думаю общую идею вы сможете уловить.
Хотя ИМХО все эти “решения” создают больше проблем чем решают.

Если уж хотите чегонить нарыть гуглите “python self hell”

Посмотрите, пожалуйста, два последних слова в топике.

FishHook
Дядя? К жене? Экий ты затейник.

Там написано "Ну-ка объясни дяде." К тому же нет запятой, которую используют при обращении.

AlekseyPython
Второй раз напишу: я ничего не объединяю в пакеты и не создаю компоненты.

Понимаешь, вся эта модульная система, пакетная система хоть в каком языке сделана не просто так. Она несёт определённую функцию в разработке проекта. Пакет или модуль является абстракцией. Мы берём эту абстракцию и используем. Мы просим её сделать что-то. Например, пакет “Машина” включает в себя всё, что касается машины. Мы можем с его помощью собрать машину, починить машину, запустить машину. То, как это делается, лежит полностью на этом пакете (пакет - это набор модулей, а модуль - набор классов, а класс - набор операций). Поэтому когда тебе надо взять машину и поехать на ней в другом проекте, ты её не пишешь с нуля, а берёшь пакет “Машина” и копируешь его в другой проект. Таким образом ты сегодня написал одну машину, а завтра использовал её в десяти разных проектах. Так ты экономишь своё время. Потом всё сводится к сборке нового проекта путём копирования в него уже разработанных пакетов. Так за день можно написать большую программу. Ну и пакет может быть компонентом программы, но и компонент программы может состоять из нескольких пакетов. Понимаешь масштабы?

http://www.imageup.ru/img87/3228879/car.png.html

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

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

py.user.next, спасабо за теорию.