Приветствую!
Наконец то руки дошли пощупать питон... Пока что щупаю 2,6 версию.
Уважаемые, объясните пожалуйста, как в нем нужно создавать новые экземпляры классов? Как передавать параметры в конструктор родителя?
S>Приветствую! S>Наконец то руки дошли пощупать питон... Пока что щупаю 2,6 версию. S>Уважаемые, объясните пожалуйста, как в нем нужно создавать новые экземпляры классов? Как передавать параметры в конструктор родителя?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую! S>Наконец то руки дошли пощупать питон... Пока что щупаю 2,6 версию. S>Уважаемые, объясните пожалуйста, как в нем нужно создавать новые экземпляры классов? Как передавать параметры в конструктор родителя?
Приветствую, Sheridan, вы писали:
S> Приветствую! S> Наконец то руки дошли пощупать питон... Пока что щупаю 2,6 версию. S> Уважаемые, объясните пожалуйста, как в нем нужно создавать новые экземпляры классов? Как передавать параметры в конструктор родителя?
Наверно плохо объяснил...
Вот код:
class a:
data = {}
def __init__(self, var, val):
self.data[var] = val
def dump(self):
print self.data
class b(a):
def __init__(self, val):
self.data['0'] = val
ca0 = a('a', 'aa')
ca0.dump()
cb0 = b('1')
cb0.dump()
ca1 = a('b', 'bb')
ca1.dump()
cb0 = b('2')
cb0.dump()
1. Как сделать так, чтобы создавать экземпляры классов, чтобы питон не пользовал один и тотже экземпляр каждый раз, что видно по выводу:
Приветствую, Курилка, вы писали:
К> — это канает на первый вопрос?
Нет, питоне не создает экземпляры похоже, а пользует один и тотже.
К> Ответ на 2-й вопрос в районе super(type[, object-or-type])
Взял оттуда пример, чуть дописал..
class B:
def method(self, arg):
print ("-- %s --" % arg)
# example ---
class C(B):
def method(self, arg):
super(C, self).method(arg)
# example ---
c = C()
c.method('!!!')
Вот вывод:
eee-sheridan munin # ./tp
Traceback (most recent call last):
File "./tp", line 60, in <module>
c.method('!!!')
File "./tp", line 57, in method
super(C, self).method(arg)
TypeError: super() argument 1 must be type, not classobj
S>> Приветствую! S>> Наконец то руки дошли пощупать питон... Пока что щупаю 2,6 версию. S>> Уважаемые, объясните пожалуйста, как в нем нужно создавать новые экземпляры классов? Как передавать параметры в конструктор родителя?
S>Наверно плохо объяснил... S>Вот код: S>
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Sheridan, вы писали:
S>> Приветствую! S>1. Как сделать так, чтобы создавать экземпляры классов, чтобы питон не пользовал один и тотже экземпляр каждый раз, что видно по выводу:
class a:
def __init__(self, var, val):
self.data = { var: val }
def dump(self):
print self.data
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Курилка, вы писали:
К>> — это канает на первый вопрос? S>Нет, питоне не создает экземпляры похоже, а пользует один и тотже.
Ты путаешь переменные класса и переменные объекта.
К>> Ответ на 2-й вопрос в районе super(type[, object-or-type]) S>Взял оттуда пример, чуть дописал.. S>
...
S>
S>Вот вывод: S>
S>eee-sheridan munin # ./tp
S>Traceback (most recent call last):
S> File "./tp", line 60, in <module>
S> c.method('!!!')
S> File "./tp", line 57, in method
S> super(C, self).method(arg)
S>TypeError: super() argument 1 must be type, not classobj
S>
Здравствуйте, Temoto, Вы писали:
T>Три простых правила. T>1. имена классов начинаются с заглавных букв.
В стандартной библиотеке это сплошь и рядом нарушается, и ничего — как-то живы:)
T>2. в первый год питона нельзя объявлять аттрибуты классов.
T>class A: T> class_attr = нельзя
T> def __init__(self): T> self.instance_attr = 'можно'
Это очень вредный совет. Атрибуты класса задают дефолтные значения и одновременно объявляют сам факт наличия такого атрибута. Если перестать их объявлять, как минимум начинаешь сбивать с толку pychecker и аналоги, замусоривая отчёты бессмысленными сообщениями и теряя в них полезные жалобы.
Разумеется, с атрибутами класса, так же как с дефолтными значениями в функциях, надо поступать осторожно. У меня была ситуация, когда я написал x = [] не в конструкторе, а в классе, и список стал общим на весь класс. Пришлось срочно апгрейдить код на десятке живых систем.:) Но твоё лечение хуже болезни.
T>3. до третьей версии питона необходимо наследовать все свои классы от object.
T>class A: нельзя T>class A(object): можно
Бессмыслица, кроме случаев, когда тебя всегда и во всём интересуют свойства new-style классов. Разумеется, у них много полезных свойств, но местами и вредных. Пару раз сталкивался с тем, что от перехода на new style происходило резкое торможение, приходилось рефакторить логику. Для нового кода я соглашусь с этим правилом, для поддержки старого — категорически нет.
T>>2. в первый год питона нельзя объявлять аттрибуты классов.
T>>class A: T>> class_attr = нельзя
T>> def __init__(self): T>> self.instance_attr = 'можно'
N>Это очень вредный совет. Атрибуты класса задают дефолтные значения и одновременно объявляют сам факт наличия такого атрибута. Если перестать их объявлять, как минимум начинаешь сбивать с толку pychecker и аналоги, замусоривая отчёты бессмысленными сообщениями и теряя в них полезные жалобы.
В динамическом (это важно) языке Python нет понятия "факт наличия аттрибута". Вы, может быть, что-то осмысленное подразумевали под этими словами, но я не понял.
А у меня pylint находит self.foo = '' и не замусоривает отчёт. Чините вашу проверялку.
Я понимаю, конечно, надо покритиковать всё. И жара, и дым, всё это влияет на людей. Я дал советы человеку, который задал первый вопрос по питону. И для него они, на мой взгляд, полезны. И пусть он через пол-года скажет: вредные это были советы или нет. Когда он разберётся в тонкостях классовых аттрибутов и new-style классов, тогда будет сам умышленно нарушать эти правила. И это тоже будет нормально.
Здравствуйте, Temoto, Вы писали:
T>>>2. в первый год питона нельзя объявлять аттрибуты классов.
T>>>class A: T>>> class_attr = нельзя
T>>> def __init__(self): T>>> self.instance_attr = 'можно'
N>>Это очень вредный совет. Атрибуты класса задают дефолтные значения и одновременно объявляют сам факт наличия такого атрибута. Если перестать их объявлять, как минимум начинаешь сбивать с толку pychecker и аналоги, замусоривая отчёты бессмысленными сообщениями и теряя в них полезные жалобы.
T>В динамическом (это важно) языке Python нет понятия "факт наличия аттрибута".
С каких это пор? Если написано a.x и x не существует, будет ошибка.
T> Вы, может быть, что-то осмысленное подразумевали под этими словами, но я не понял.
Да, осмысленное.
T>А у меня pylint находит self.foo = '' и не замусоривает отчёт. Чините вашу проверялку.
У pylint достаточно граблей, чтобы его не использовать. pychecker в целом оказался значительно более вменяемым.
T>Я понимаю, конечно, надо покритиковать всё. И жара, и дым, всё это влияет на людей.
Не надо пытаться сводить позицию собеседника к влиянию жары. Кстати, дыма у нас нет.
T> Я дал советы человеку, который задал первый вопрос по питону. И для него они, на мой взгляд, полезны. И пусть он через пол-года скажет: вредные это были советы или нет. Когда он разберётся в тонкостях классовых аттрибутов и new-style классов, тогда будет сам умышленно нарушать эти правила. И это тоже будет нормально.
Речь никак не о новичке и Sheridan в состоянии выбрать грамотный совет из нескольких.
T>>>>class A: T>>>> class_attr = нельзя
T>>>> def __init__(self): T>>>> self.instance_attr = 'можно'
N>>>Это очень вредный совет. Атрибуты класса задают дефолтные значения и одновременно объявляют сам факт наличия такого атрибута. Если перестать их объявлять, как минимум начинаешь сбивать с толку pychecker и аналоги, замусоривая отчёты бессмысленными сообщениями и теряя в них полезные жалобы.
T>>В динамическом (это важно) языке Python нет понятия "факт наличия аттрибута".
N>С каких это пор? Если написано a.x и x не существует, будет ошибка.
Этот пример как раз игнорирует выделенное слово "динамическом". Попытаюсь объяснить, что я имел в виду. Два пункта:
1) объявление аттрибута класса (или инстанса) не даёт гарантии, что позже a.x не поднимет AttributeError. Вот в Си поле структуры будет всегда, да, это неизменный факт, а тут нет. Факт наличия аттрибута может быть разным в двух разных попытках доступа к аттрибуту (примеры нужны?). Строго говоря, это конечно, всё ещё "факт", но пользы от изменяющегося факта имхо, мало.
2) "аттрибуты класса объявляют факт наличия такого аттрибута". Это скорее похоже на личную привычку и ожидания от своего кода. Т.е. "я пишу такой код, в котором для себя и будущих читателей обозначаю аттрибутами класса какие аттрибуты я потом буду использовать". Потому что во-первых, я не встречал никаких официальных рекомендаций подобной этой; а в отсутствие таковых, глядя на код других программистов, могу уверенно сказать, что гораздо чаще (на моём опыте) факт наличия аттрибута объявляется именно через self.attr в __init__.
Другими словами, ткните меня носом в какой-нибудь документ, который задаёт аттрибутам класса именно такую семантику, как вы описали выше. Иначе, можно считать что мы просто по-разному воспринимаем смысл и предназначение классовых аттрибутов и обе точки зрения не "вредные".
T>> Вы, может быть, что-то осмысленное подразумевали под этими словами, но я не понял. N>Да, осмысленное.
Что?
T>>А у меня pylint находит self.foo = '' и не замусоривает отчёт. Чините вашу проверялку.
N>У pylint достаточно граблей, чтобы его не использовать. pychecker в целом оказался значительно более вменяемым.
Наверное, я не сравнивал. Ну вот, есть очевидный баг в pychecker и есть повод его исправить.
T>>Я понимаю, конечно, надо покритиковать всё. И жара, и дым, всё это влияет на людей.
N>Не надо пытаться сводить позицию собеседника к влиянию жары. Кстати, дыма у нас нет.
Здравствуйте, Temoto, Вы писали:
N>>С каких это пор? Если написано a.x и x не существует, будет ошибка. T>Этот пример как раз игнорирует выделенное слово "динамическом". Попытаюсь объяснить, что я имел в виду. Два пункта: T>1) объявление аттрибута класса (или инстанса) не даёт гарантии, что позже a.x не поднимет AttributeError. Вот в Си поле структуры будет всегда, да, это неизменный факт, а тут нет. Факт наличия аттрибута может быть разным в двух разных попытках доступа к аттрибуту (примеры нужны?). Строго говоря, это конечно, всё ещё "факт", но пользы от изменяющегося факта имхо, мало.
Верно, но есть принципиальное различие между подходами, когда стремятся сделать управляемую обстановку и работать в её рамках, и тем, когда принципиально "хачат" для создания трюков и странных решений. В случае Питона никто не мешает вызвать delattr(), но это уже хак, точно так же как в Си, когда подсунут указатель на что-то несуществующее или недопустимое (и неважно, что формально можно достучаться к элементу).
В случае Питона, усреднённым нормативным подходом является то, что когда пишут z.x, предполагают, что у объекта z есть атрибут x и это обусловлено всем контекстом исполнения. И если x это переменная (а не что-то хитрое, реагирующее на __getattribute__()) — то ей крайне желательно существовать всё время жизни любого объекта класса этого z — иначе статическая проверка на допустимость z.x не пройдёт.
T>2) "аттрибуты класса объявляют факт наличия такого аттрибута". Это скорее похоже на личную привычку и ожидания от своего кода. Т.е. "я пишу такой код, в котором для себя и будущих читателей обозначаю аттрибутами класса какие аттрибуты я потом буду использовать". Потому что во-первых, я не встречал никаких официальных рекомендаций подобной этой; а в отсутствие таковых, глядя на код других программистов, могу уверенно сказать, что гораздо чаще (на моём опыте) факт наличия аттрибута объявляется именно через self.attr в __init__.
Не знаю, где Вы видите код других программистов, но я смотрю в качестве хорошего примера на стандартную библиотеку. В стандартной библиотеке общей тенденции нет, но объявление в классе используется более чем в половине случаев. Задание же значения в конструкторе безусловно необходимо только при получении из аргументов или если иначе не получится переменная объекта.
T>>>А у меня pylint находит self.foo = '' и не замусоривает отчёт. Чините вашу проверялку. N>>У pylint достаточно граблей, чтобы его не использовать. pychecker в целом оказался значительно более вменяемым. T>Наверное, я не сравнивал. Ну вот, есть очевидный баг в pychecker и есть повод его исправить.
Это не баг.
T>>>Я понимаю, конечно, надо покритиковать всё. И жара, и дым, всё это влияет на людей. N>>Не надо пытаться сводить позицию собеседника к влиянию жары. Кстати, дыма у нас нет. T>Это шутка такая.
T>>2) "аттрибуты класса объявляют факт наличия такого аттрибута". Это скорее похоже на личную привычку и ожидания от своего кода. Т.е. "я пишу такой код, в котором для себя и будущих читателей обозначаю аттрибутами класса какие аттрибуты я потом буду использовать". Потому что во-первых, я не встречал никаких официальных рекомендаций подобной этой; а в отсутствие таковых, глядя на код других программистов, могу уверенно сказать, что гораздо чаще (на моём опыте) факт наличия аттрибута объявляется именно через self.attr в __init__.
N>Не знаю, где Вы видите код других программистов, но я смотрю в качестве хорошего примера на стандартную библиотеку. В стандартной библиотеке общей тенденции нет, но объявление в классе используется более чем в половине случаев. Задание же значения в конструкторе безусловно необходимо только при получении из аргументов или если иначе не получится переменная объекта.
То есть, на одной чаше весов у нас субъективное восприятие, что именно аттрибут класса устанавливает факт наличия аттрибута и pychecker, который не работает с аттрибутами заданными иначе. На другой — субъективное восприятие, что аттрибуты создаются в __init__, pylint, который понимает оба варианта и потенциальные баги с мутабельными аттрибутами класса.
T>>>>А у меня pylint находит self.foo = '' и не замусоривает отчёт. Чините вашу проверялку. N>>>У pylint достаточно граблей, чтобы его не использовать. pychecker в целом оказался значительно более вменяемым. T>>Наверное, я не сравнивал. Ну вот, есть очевидный баг в pychecker и есть повод его исправить.
N>Это не баг.
Хакей, конечно, это фича. Но этот не-баг противоречит вышеупомянутому усреднённому нормативному подходу, правда?
Я имею в виду, что если я напишу
class Truboji(list):
def __init__(self):
self.ji_size = 0
print Truboji().ji_size
живой программист не удивится доступу к аттрибуту ji_size и я ожидаю, что проверялка тоже скажет "проблем нет".
Здравствуйте, Temoto, Вы писали:
N>>Не знаю, где Вы видите код других программистов, но я смотрю в качестве хорошего примера на стандартную библиотеку. В стандартной библиотеке общей тенденции нет, но объявление в классе используется более чем в половине случаев. Задание же значения в конструкторе безусловно необходимо только при получении из аргументов или если иначе не получится переменная объекта.
T>То есть, на одной чаше весов у нас субъективное восприятие, что именно аттрибут класса устанавливает факт наличия аттрибута и pychecker, который не работает с аттрибутами заданными иначе. На другой — субъективное восприятие, что аттрибуты создаются в __init__, pylint, который понимает оба варианта и потенциальные баги с мутабельными аттрибутами класса.
Именно так. Но есть один нюанс: описание состава класса соответствует как отраслевой традиции (ибо не питоном единым жив программист), так и желанию увидеть, чем же именно отличаются все экземпляры данного класса. И отсюда и получается, что если какое-то поле есть у всех и какой-то метод есть у всех — он должен быть явно виден на уровне класса, без анализа, что же там за хакерство в конструкторе.
А то, что можно это перехакать до неузнаваемости — говорит разве что в пользу того, что только там, где неизвестно, будет атрибут x или нет, надо не описывать его на уровне класса. А в остальных случаях (>>90% практики) — описывать.
T>Хакей, конечно, это фича. Но этот не-баг противоречит вышеупомянутому усреднённому нормативному подходу, правда?
Которому из? Моему — не противоречит.
T>Я имею в виду, что если я напишу T>
T>живой программист не удивится доступу к аттрибуту ji_size и я ожидаю, что проверялка тоже скажет "проблем нет".
А теперь представь себе, что конструктор весит 2 экрана, несколько существенно разных веток выполнения и слишком сложно окинуть одним взглядом, чтобы узнать, в какой ветке ji_size задаётся, а в какой — нет...
T>>То есть, на одной чаше весов у нас субъективное восприятие, что именно аттрибут класса устанавливает факт наличия аттрибута и pychecker, который не работает с аттрибутами заданными иначе. На другой — субъективное восприятие, что аттрибуты создаются в __init__, pylint, который понимает оба варианта и потенциальные баги с мутабельными аттрибутами класса.
N>Именно так. Но есть один нюанс: описание состава класса соответствует как отраслевой традиции (ибо не питоном единым жив программист), так и желанию увидеть, чем же именно отличаются все экземпляры данного класса. И отсюда и получается, что если какое-то поле есть у всех и какой-то метод есть у всех — он должен быть явно виден на уровне класса, без анализа, что же там за хакерство в конструкторе.
N>А то, что можно это перехакать до неузнаваемости — говорит разве что в пользу того, что только там, где неизвестно, будет атрибут x или нет, надо не описывать его на уровне класса. А в остальных случаях (>>90% практики) — описывать.
N>А теперь представь себе, что конструктор весит 2 экрана, несколько существенно разных веток выполнения и слишком сложно окинуть одним взглядом, чтобы узнать, в какой ветке ji_size задаётся, а в какой — нет...
Ваши аргументы работают в случае предвзятого предположения, что на уровне класса несколько коротких объявлений, а в __init__ почему-то два экрана разных веток. И нет ничего страшного в этой предвзятости, это понятно, потому что вы (зачем-то, вот это мне непонятно) пытаетесь доказать, что использовать аттрибуты классов "лучше". А вот что не нормально, так это то, что вы не рассматриваете противоположный вариант, когда у класса аттрибутов нет, а в __init__ несколько коротких объявлений. Справедливость в споре должна быть или нет?
Пожалуйста, обратите внимание, что после расстановки аргументов за и против, я не делал никаких категоричных выводов, что лучше, что хуже. Наоборот, это было своего рода предложение тихо остановиться. До тех пор, пока программа работает как надо все варианты хороши. Уверен, что мы с лёгкостью прочитаем код друг друга, потому что понимаем как всё работает и не творим откровенный беспредел. Также, я уверен, что вы внезапно не перестанете писать аттрибуты классам, а я не начну. Так к чему этот спор?
