Вот как раз в тех патчах, о которых Вы говорите, реклама пряталась, но её загрузка всё равно выполнялась, потому что автор патчей орудовал редакторами ресурсов, а никак не дизассемблером.
Нет, QIP не загружает рекламу. В логах прокси есть только обращения к login-серверу, затем, видимо, клиент получает адрес, куда нужно пересоединиться и держит с тем сервером постоянное подключение. Параллельно QIP запрашивает с серверов ICQ данные о аватарках пользователей. И всё.
Ммм… я тестировал именно «рафинированные случаи» — производительность самих методов, если считать, что объект не желает странного. Методы — эквивалентны, они всегда, везде, при любых условиях (кроме dir, но это отдельный разговор) возвращают булево значение — существует атрибут или нет. Даже при наличии __getattr__/__getattribute__ эти методы будут работать нормально, если «перехватчики» умеют сваливаться с AttributeError() при эмуляции отсутствии атрибута.
Да, переделал тест на работу с __getattribute__, запустил, жду, пока результаты будут.
А насчет получения самого __dict__ — я не помню точно, где и как, но мне встречалась ситуация, где методу __getattribute__(self, name) передавался в качестве name'__dict__'.
Ой, а таки щито ви имеете пготив самописных алгоритмов? :)
Если серьезно, не вижу в «самописности» ничего плохого — хотя бы потому, что для каждой отдельно взятой задачи можно создать такой алгоритм, который будет решать её максимально оптимально, вместо того, чтобы использовать какие-либо алгоритмы для общих случаев и накручивать «обёртки» для достижения своей цели.
А getattr(obj, name, None) is not None я проверил:
Таким образом, видно, что в общем случае getattr лучше прямого запроса свойства и отработку AttributeError, но хуже hasattr. Удивительно, но этот результат противоречит документации, потому что если hasattr реализован через getattr, то они должны были поменяться местами в общем рейтинге.
В персональном зачете getattr показывает себя с лучшей стороны, чем обработка исключения, и, думаю, его можно использовать там, где его можно использовать :) — в отличии от hasattr, он возвращает значение элемента.
Самый первый вопрос: стоит ли шкурка вычинки? Стоило ли проделывать такое количество работы ради получения очевидных результатов? Помоему достаточно иметь общее представление о затратах на каждый из методов.
Думаю, стоит. Я не берусь утверждать, что результаты очевидны для всех. Работы в действительно было потрачено немного. А данный тест и даёт общее представление о затратах на каждый из методов — для получения более подробной статистики уже в (полу)готовом приложении можно использовать профайлер :)
__dict__ — поиск значения в ассоциативном массиве. Что может быть быстрее? Только прямое обращение к атрибуту, если он есть...
Хммм… А разве обращение к атрибуту «напрямую» не есть поиск в __dict__?
hasattr — реализован через getattr и исключения. Тогда очевидно, что по времени затраты будут примерно такие же как и на отдельную проверку getattr с отловом исключения (при наличие атрибута — быстро, при отсутствие — медленно).
Если бы hasattr был реализован как getattr с проверкой исключения, то тогда тесты exc_getattr и hasattr показали бы одинаковые результаты — а это не так. Скорее, hasattr проходит по всем __dict__-ам, начиная от экземпляра класса и заканчивая самым «глубоким» объектом класса, осуществляя lookup во всех классах. Возможно, я ошибаюсь — нужно смотреть в исходники Python.
dir — достаточно оценить время выполнения этой функции и сравнить с поиском в ассоциативном массиве.
Я взял эту функцию единственно потому, что в одном проекте, написанном доблестными индусскими программистами, dir() используется именно с этой целью :)
Кстати, а как на счет getattr(obj, attr_name, None)? Имхо, если атрибут не найден, это должно работать быстрее, чем бросать исключение.
Идея хороша, в принципе, но в общем случае неприменима — атрибут может иметь значение None, и тогда будет непонятно, есть ли атрибут или нет.
Но в любом случае, наглядные результаты всегда надежней, чем сухая теория :)
По совету cleg-а провёл замер скорости выполнения с помощью этого кусочка кривого кода. Мерялось на Celeron 2.53GHz. Результат: One pass takes 0.000043 sec.
Также отмечу, что для задания кодировки более чем достаточно просто написать # coding: utf8 (или koi8-r, или cp1251, или cp866), не занимаясь лишним украшательством звёздочками и черточками.
dir, но это отдельный разговор) возвращают булево значение — существует атрибут или нет. Даже при наличии__getattr__/__getattribute__эти методы будут работать нормально, если «перехватчики» умеют сваливаться с AttributeError() при эмуляции отсутствии атрибута.Да, переделал тест на работу с __getattribute__, запустил, жду, пока результаты будут.
__dict__— я не помню точно, где и как, но мне встречалась ситуация, где методу__getattribute__(self, name)передавался в качествеname'__dict__'.Если серьезно, не вижу в «самописности» ничего плохого — хотя бы потому, что для каждой отдельно взятой задачи можно создать такой алгоритм, который будет решать её максимально оптимально, вместо того, чтобы использовать какие-либо алгоритмы для общих случаев и накручивать «обёртки» для достижения своей цели.
А
getattr(obj, name, None) is not Noneя проверил:Групповой зачет:
getattr : 15.350072 [0 subtests failed]
Персональный зачет:
test_getattr_true_this_ca : 7.596199
test_getattr_true_parent_ca : 7.865653
test_getattr_true_this_ia : 8.003450
test_getattr_true_parent_ia : 8.811715
test_getattr_false : 22.630889
Таким образом, видно, что в общем случае
getattrлучше прямого запроса свойства и отработкуAttributeError, но хужеhasattr. Удивительно, но этот результат противоречит документации, потому что еслиhasattrреализован черезgetattr, то они должны были поменяться местами в общем рейтинге.В персональном зачете
getattrпоказывает себя с лучшей стороны, чем обработка исключения, и, думаю, его можно использовать там, где его можно использовать :) — в отличии отhasattr, он возвращает значение элемента.Думаю, стоит. Я не берусь утверждать, что результаты очевидны для всех. Работы в действительно было потрачено немного. А данный тест и даёт общее представление о затратах на каждый из методов — для получения более подробной статистики уже в (полу)готовом приложении можно использовать профайлер :)
Хммм… А разве обращение к атрибуту «напрямую» не есть поиск в
__dict__?Если бы
hasattrбыл реализован какgetattrс проверкой исключения, то тогда тестыexc_getattrиhasattrпоказали бы одинаковые результаты — а это не так. Скорее,hasattrпроходит по всем__dict__-ам, начиная от экземпляра класса и заканчивая самым «глубоким» объектом класса, осуществляя lookup во всех классах. Возможно, я ошибаюсь — нужно смотреть в исходники Python.Я взял эту функцию единственно потому, что в одном проекте, написанном доблестными индусскими программистами,
dir()используется именно с этой целью :)Идея хороша, в принципе, но в общем случае неприменима — атрибут может иметь значение None, и тогда будет непонятно, есть ли атрибут или нет.
Спасибо :)
8 + 7 + 10 + 4 == 294 + 9 + 5 + 8 == 26
Хочется продолжить последовательность числом 23.
7 + 3 + 6 + x == 23x == 7
Вариант решения №2
7 XOR 4 XOR 8 == 113 XOR 9 XOR 7 == 13
6 XOR 5 XOR 10 == 9
Видим последовательность 11, 13, 9, т.е. +2, -4, возможно, там будет опять +2, т.е.
9 + 2 == 11.x XOR 8 XOR 4 == 11x == 7
Естественно, всё это на уровне догадок… Если не секрет, какой правильный ответ на первый вопрос и почему он такой?
One pass takes 0.000043 sec.Также отмечу, что для задания кодировки более чем достаточно просто написать
# coding: utf8(или koi8-r, или cp1251, или cp866), не занимаясь лишним украшательством звёздочками и черточками.