Lexander
Ноя. 6, 2009 19:55:17
Скорее не противоречия, а ограничения. Но я их и так вижу и они мне понятны.
Основная идея, как я уже писал выше, уменьшить количество работы (не самой интересной в процессе создания ПО) для кодера путем сокращения нотации. А, так как это невозможно, то я принимаю Питон таким как он есть, хоть и ворчу :) по поводу “избыточности”.
crchemist
Ноя. 6, 2009 19:59:47
Gradient
Зачем при написании метода класса всегда указывать self? Понятно, что “объектная ориентированность реализована так”, но код-то зачем этим забивать? В “других языках” интерпретатор с таким отлично справляется без пихания self на каждый чих.
Lexander
Из всего вышеперечисленного только self поддерживаю. Остальное - на любителя.
Lexander
Зачем магия. Есть перечень свойств и методов класса, оттуда их брать. Речь идет о том, чтобы сократить запись обращения к ним внутри класса.
необовязково передавати self. можна написати шось таке і не паритись:
[crchemist@17-140-179-94 tmp]$ cat main.py
from types import FunctionType
def wrap(f):
def hidden_self(self):
f.func_globals['self'] = self
return f()
return hidden_self
class NoSelf(type):
def __init__(cls, cls_name, base, attrs):
for key, value in attrs.items():
if type(value) == FunctionType:
setattr(cls, key, wrap(value))
class NoSelfClass(object):
__metaclass__ = NoSelf
a = 15
def f():
self.a = 3
def print_a():
print self.a
a = NoSelfClass()
a.print_a()
a.f()
a.print_a()
[crchemist@17-140-179-94 tmp]$ python main.py
15
3
[crchemist@17-140-179-94 tmp]$
цей код працює; хоча певно має багато недоробок; але думаю якшо все гарно підправити - то можна self забрати; просто вказувати в описі класу __metaclass__=NoSelf
crchemist
Ноя. 6, 2009 20:06:41
і взагалі з
http://python.su/forum/viewtopic.php?pid=35886#p35886 цього поста якщо захотіти - можна все обійти; треба просто написати декілька своїх ф-нкцій і використовувати їх; хоча фігня це все…
Андрей Светлов
Ноя. 7, 2009 04:08:41
crchemist
+1
Если захотеть - можно выкрутиться, тут вы правы. И NoSelf можно сделать лучше, не используя глобальную переменную self.
Только - это все действительно полная фигня.
Явный оффтоп. Было бы занятно устроить соревнование: а что нельзя выкрутить в питоне - и сложные задачки в студию!
Lexander, я подразумевал следующее: если попытаетесь не только сформулировать, что вам не нравиться - а еще и набросать желаемую реализацию - лучше поймете, почему сделано так, а не иначе. И почему это - правильно.
Кстати, есть и довольно занятные идеи, которые были отложены “до лучших времен”.
Например, такая (обсуждалась в python-ideas меньше месяца назад): добавить в метод стандартные аттрибуты __class__, __module__, __func__.
Примерно как каждый класс имеет свой __module__. Да только выяснилось, что сейчас сделать это без потери производительности нереально - но штука хорошая. Просто в стеке нет нужных данных - а вносить их на каждый call довольно дорого.
Была и другая - “расслабить” правила на синтаксис декоратора. Сейчас это имя или вызов. Т.е. нельзя написать
@deco
def f(…):
…
Я был удивлен - но действительно нельзя. Казалось бы - ничего не мешает сделать синтаксис в виде @выражение, где выражение - любой expression Питона.
Гвидо сказал, что это было неслучайно - он хотел сохранить use cases для декораторов максимально простым и понятным. И привел несколько примеров абсолютно нечитаемых @expressions. Более того - часть вообще не имела смысла. Хотя квадратные скобки для некоторых (очень малое число) применений выглядят логично. Гвидо ссылался на то, что “своей задницей чует - так не нужно, чтобы вдруг и сразу - выражение”. Быстро договорились: задница ван Россума - великолепный индикатор. Множество решений по языку, которые он делал опираясь на это неоднозначное чувство - оправдали себя. Выражение в декоратор вставлять нельзя - а когда недовольные соберут значимое количество примеров - возможно, ограничение чуть-чуть “облегчат”.
И такое сплошь и всюду: __doc__ для класса - неизменяемый атрибут (а в функции его можно менять - это требуется для работы functools.wraps и создания “правильных” декораторов вообще). Потому что Гвидо кажется, что он должен создаваться при написании класса - и потом его менять не следует. И пока не увидит значимых причин поменять поведение - так все и будет.
Я его понимаю и поддерживаю.
Когда слишком много дозволено - получается бардак. И, более того, выползают “странные” баги.
bialix, например, писал относительно недавно на этом форуме о том, что на новеньком PyQt QBzr (замечательная штука, между прочим - я QBzr имел в виду) - падала с весьма странной ошибкой. Грешил на sip, который используется PyQt для “заматывания” Qt библиотеки. Его проблемы не видел - я тоже использую не “самую последнюю версию” и основной Питон у меня все еще 2.5 - так было нужно.
Зато споткнулся на другом: sip не поддерживает присваивания в __dict__ объекта. Вообще. Видимо, автору это показалось не нужным - он и забил.
Сделал setattr и поддержал __dict__ - который много кому нужен. Да вот только его __dict__ не видит изменений в самом себе.
Т.е. как бы проблемы большой нет, мало кто на это наткнется - но:
- исключение не выбрасывается, оно тихонько так игнорируется. Библиотека ведет себя в стиле: кто ты? Я тебя не знаю - а ну быстро-быстро уйди из поля зрения.
- а та библиотека, которая зависит именно от присваивания в __dict__ - не работает.
Upd: новая версия (почему-то она не выпускается для 2.5, зато есть для 2.6/3.1) - работает нормально. sip починили в моих глазах - ценой краша Qbzr для Сани Бельченко.
Кажется, для своего случая _самое главное изменение_ нашел - только от легче не стало.
Сразу, что ли, писать - если питон раньше 2.6 - ошибки не будет, но программа сработает некорректно.
А теперь подумайте - как нелегко уважаемому Гвидо принимать решения. Чтобы сделать лучше - и ничего не поломать. Не в самом Питоне - а еще и в большом community.
Уменьшить возможность этих side effects.
Новое ключевое слово nonlocal было принято только после того, как сделанный анализ библиотек показал - никто его не использует.
Злой вопрос про GIL - он уже оскомину набил.
Гвидо не против избавиться от. Только ставит условия:
- даже в однопоточной программе не должно быть потери производительности
- не принимает изменений, которые бы потребовали переписывания C Extensions. Перекомпиляция - дело привычное. Но если скомпилить можно - а оно потом нестабильно работает - кому такое нужно?
Когда будет адекватная замена - приймется с “пол-пинка”. Беда в том, что как минимум Garbage Collector нужно переписать.
Ребята пытаются - но все еще не выходит сделать это “красиво”. Гвидо - наблюдает.
Когда я его спросил о GIL - о чем же еще если не о наболевшем спрашавать - он в ответ поинтерисовался: а зачем мне это было бы нужно.
Я начал говорить о большом трехмерном мире, в котором очень уж большой граф получается и разбрасывание по потокам слабо помогает…
Ответ был прост и очевиден: нужно много - задумайся о cloud computing. Потоки все равно не спасут. Нужны процессы. В перспективе - на разных компах.
Когда ответ обдумал - спрашивать было не о чем.
На сегодняшний день самыми популярными вопросами форума являются:
- почему мой re.py не желает импортировать стандартный модуль re
- почему мой модуль вообще не импортируется (читать как: что нужно сделать, чтобы путь попал в sys.paths - или обработался import hook. Впрочем, если человек дорос до второго пункта - время на ответ точно не будет потрачено зря :)
Стоит ли дальше плодить неочевидные изменения?
ван Россум полагает - нет. Не нужно.
Сначала следует “всерьез и надолго” мигрировать на тройку - она же покажет, что нужно языку и что - нет.
Я видел переход с Python 1.5 на Python 2.x - только третья версия “пошла в народ” - а до того ой как сильно сопротивлялись.
Как-то так…
Lexander
Ноя. 7, 2009 17:10:28
Спасибо за расширенный ответ.
Заинтересовался вот этим:
Андрей Светлов
добавить в метод стандартные аттрибуты __class__, __module__, __func__. Примерно как каждый класс имеет свой __module__. Да только выяснилось, что сейчас сделать это без потери производительности нереально - но штука хорошая.
Разве возможностей модуля inspect недостаточно?
Ну или sys._getframe()?
Андрей Светлов
Ноя. 7, 2009 20:37:43
Из sys._getframe можно получить только code objects - а не функцию, которая этот code object содержит. До класса - вообще не добраться. Т.е. self - это хорошо - но фрейм явно на класс не ссылается.
inspect - просто удобные функции для работы. Если во фрейме информации нет - то ничем не поможет.
При желании вся лавочка легко реализуется своими декораторами - но их нужно вставлять вручную.