Как стать автором
Обновить

Комментарии 23

Спасибо за статью, не знал про оператор @.
И вместо «расхрабриться» прочитал «расхабриться», что в этом случае даже уместней :)
Я вам даже больше скажу, изначально там именно так и было, только при предфинальной вычитке заметил, была даже идея, поставить там строчную «Р», но вы правы, оба слова подходят.
Да, спасибо, сколько пишу на python, а все время узнаю что-то новое. Даже не догадывался об операторе @.
>>> карма_писателя = 10
>>> #  Карма писателя после этой статьи:
... карма_писателя += 10
>>> карма_писателя
20

Хотел еще после первой статьи ссылку кинуть, но не смог зайти. Вот еще немного интересненького про python
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
Ну с точки зрения математики умножение на скаляр N — это сложение объекта с самим собой N раз. Вот python и складывает строку саму с собой 2 раза, со списками и кортежами так тоже можно.
Маленькое дополнение/пояснение по поводу атрибутов класса.
В питон следует различать класс как таковой и его экземпляры. Если в объявлении класса вы укажите не только методы, но и атрибуты, то эти атрибуты разделят между собой все экземпляры класса. Поведение таких атрибутов аналогично static значениям во многих других языках. Для доступа к таким значениям не обязательно создавать инстанс класса, можно через точку, как к атрибуту типа.
Атрибуты класса можно создавать и инициализировать в реализации метода __init__, который играет роль конструктора экземпляра, или динамически. В случае, когда динамическое создание атрибутов нежелательно, можно в декларации класса объявить массив __slots__, с перечислением имен всех доступных атрибутов, и питон не позволит создавать ни какие другие атрибуты, кроме этих.
Спасибо, я именно это и хотел сказать, но у вас получилось понятнее.
Про __slots__ думал в следующих статьях написать, но пока не придумал, как это получше сделать, наверно, стоило прямо здесь и сказать сразу после примера с добавлением полей, но по хорошему, надо ещё и механизм, как это обеспечивается описать, а я пока не разбирался.
Мне кажется об этом правильнее рассказывать по-другому.
1. У объекта могут быть атрибуты.
2. Класс — это тоже объект.
3. При обращении к атрибуту объекта (через точку или getattr) поиск происходит сначала в контексте самого объекта, потом в контексте его классов.
4. Запись атрибута происходит в контекст самого объекта.
3. При обращении к атрибуту объекта (через точку или getattr) поиск происходит сначала в контексте самого объекта, потом в контексте его классов.
Главное не переборщить, чтобы не получилось каши. Обычно, имена хранятся в массиве __dir__, но есть еще слоты, а еще __getattr__ и __getattribute__, которые могут быть перекрыты, и реализовывать вычислимые атрибуты, и не только их. И это только про текущий контекст. А еще, если я не ошибаюсь, то логика поиска имен в родительских классах для второй и третей ветки различается. И чтобы было совсем весело, можно расказать о загрузке пакетов и классов, здесь тоже, если я не путаю, есть различия, потому что третий питон старается бороться с циклическим импортом.
Да, вы правы, всегда можно погрузиться еще глубже. Мне кажется, что осваивать такие вещи новичкам нужно поэтапно. Выделить начальные этапы так, чтобы их описание не вводило в заблуждение при погружении в более глубокие слои — это искусство преподавания.
Спасибо, интересно.
Что-то разочаровало меня то, как устроены булевы типы, а именно наследование от целочисленного типа. В прошлой статье пример со словарём мягко говоря вообще не обрадовал.
Ярче всего идею, что python это не java иллюстрирует то, что добавление полей в объектах и классах осуществляется через обычное присваивание


Спасибо за наводку. Я даже предположить не мог что такое возможно. Это же прямое нарушение принципов ООП? или Питон не является объектно ориентированным?
Каким образом? Они как раз запрещают прямое изменения членов класса, для того чтобы сохранить все внутренние зависимости.
Какого принципа? Инкапсуляции? Как уже было сказано, этот принцип нарушается и в хвост, и в гриву.
И как можно быть не объектно-ориентируемым, но поддерживать создание классов и объектов?)
Вообще существует множество видений ООП, и видение Java, насколько я могу судить, ни чуть не ближе к Smalltalk, чем python и Java между собой.
Принципа абстракции.
Если определять язык программирования объектно ориентированным только по наличию конструкций для создания классов, объектов — то да. Только вот чем класс в Питоне отличается от просто контейнера, в который можно напихать что угодно?
Не совсем понимаю, каким образом.
И изначальная идея сферических объектов в памяти, которые обмениваются сообщениями и сами решают, когда им сообщение обработать и в какое состояние перейти, тоже довольно далековата от чего-то хранящее методы и переменные, которые может дёргать любой дурак.
Является. Если кто-то и нарушит эти принципы, то это будет программист. Он это сделает либо нарочно, а значит это его дело, либо нечаянно — такие ошибки надо искать линтерами. Просто питон не налагает лишних ограничений и не разводит бюрократию. Это позволяет ему быть лаконичным и простым.

Нарушение каких принципов? Если вы имеете в виду инкапсуляцию, то не надо путать это понятие с сокрытием данных. Инкапсуляция — это по сути размещение в одном объекте данных и функций, которые используют и/или изменяют эти данные. В Python нет сокрытия данных и это не нарушает никакие принципы ООП.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации