Последние Записи.
Музей народной архитектуры
Был на этих выходных в Пирогово, это под Киевом, место довольно красивое. Смотрел на дома от 17 до 20 столетия. И ведь еще простоят много лет и даже жить в некоторых можно.
Посмотрел на ветряные мельницы, водяные, был внутри хозяйства зажиточного крестьянина, заходил в церковь, походил по болотной местности, что лежит вообще за пределами музея.
В итоге, за время пребывания там мы прошли все Закарпатье, Подолье, Полесье, и другие районы украинской земли.
Шизофреник
Насколько простым и гениальным может быть лого? А вот я вам скажу) Лично мне оно понравилось
А вот собсно место, откуда чесно взял.
hasattr и __dict__
Заметил что hasattr в коей мере некорректно работает на определение наличия аттрибута в классе, пришлось отказаться от него и использовать такую проверку
-
if "value" not in MyClass.__dict__:
-
pass
Какие минусы этого подхода полностью не знаю, но знаю что может привести в определенных ситуациях к зацикливанию, это в случае если использовать __setattr__ в паре с ним. Может у кого-то другие подходы? Или просвятит на предмет использования __dict__ :-)
Динамическое создание объектов
Простой трюк если вам необходимо создать объект из его названия.
Для себя я нашел простой набор функций
-
def _get_mod(modulePath):
-
return __import__(modulePath, globals(), locals(), [‘*’])
-
-
-
def _get_func(fullFuncName):
-
"""Retrieve a function object from a full dotted-package name."""
-
-
# Parse out the path, module, and function
-
lastDot = fullFuncName.rfind(u".")
-
funcName = fullFuncName[lastDot + 1:]
-
modPath = fullFuncName[:lastDot]
-
-
aMod = _get_mod(modPath)
-
aFunc = getattr(aMod, funcName)
-
-
# Assert that the function is a *callable* attribute.
-
assert callable(aFunc), u"%s is not callable." % fullFuncName
-
-
# Return a reference to the function itself,
-
# not the results of the function.
-
return aFunc
-
-
-
def _get_class(fullClassName, parentClass=None):
-
"""Load a module and retrieve a class (NOT an instance).
-
-
If the parentClass is supplied, className must be of parentClass
-
or a subclass of parentClass (or None is returned).
-
"""
-
aClass = _get_func(fullClassName)
-
-
# Assert that the class is a subclass of parentClass.
-
if parentClass is not None:
-
if not issubclass(aClass, parentClass):
-
raise TypeError(u"%s is not a subclass of %s" %
-
(fullClassName, parentClass))
-
-
# Return a reference to the class itself, not an instantiated object.
-
return aClass
После можно это использовать таким образом
-
model_type = _get_class("example.MyView")
Далее просто создаем экземпляр нашего класса
-
model_object = model_type()
Если надо вызвать определенный метод то достаточно воспользоваться getattr
-
getattr(model_object, ‘mymethod’)()
кваргиарги
Иногда приходится выполнять запросы по нескольким условиям из одной таблицы. Как пример выборка какой нибудь статьи сначала по названию, потом по дате. В принципе такое будет выглядеть таким образом
-
try:
-
if not objects:
-
objects = search_for(h_date__day = param)
-
except:
-
objects = []
-
-
try:
-
if not objects:
-
objects = search_for(h_date__month = 11)
-
except:
-
objects = []
Попробуем с этим что то сделать =) Для этого вспомним что такое kwargs и args и насколько полезными они часто бывают.
-
objects = search_for(title__icontains = param)
-
-
if not objects:
-
objects = search_for(h_date__day = param)
-
-
if not objects:
-
objects = search_for(h_date__month = month)
Как видно я вынес одинаковую часть в отдельный метод. Посмотрим что делает этот метод:
-
def search_for(*args, **kwargs):
-
try:
-
objects = MyModelObject.objects.filter(*args, **kwargs)
-
except:
-
objects = []
-
return objects
Ничего сверхъестественного, верно? А можно унифицировать метод и использовать его где захочется для простой фильтрации.
-
def filter_for(model, *args, **kwargs):
-
try:
-
objects = model.objects.filter(*args, **kwargs)
-
except:
-
objects = []
-
return objects
-
-
-
def func(request, param):
-
filter_for(MyModel, title_icontains = param)
Декораторы в Python
Декоратор в питоне это не одно и тоже что и декоратор в шаблонах проектирования как бы это показалось на первый взгляд. Декоратор в понимании шаблонов проектирования добавляет функциональность в runtime, а python декораторы делают это только во время определения функции. В этом и есть огромная разница между ними.
Далее под словом «декоратор» имеем ввиду python декоратор.
Декоратор определяется знаком @ и названием в начале функции. Пример (взят с вики):
-
@viking_chorus
-
def menu_item():
-
print "spam"
Данное определение эквивалентно
-
def menu_item():
-
print "spam"
-
menu_item = viking_chorus(menu_item)
Здравствуй аспектно ориентированное программирование. Теперь сам декоратор.
-
def viking_chorus(myfunc):
-
def inner_func(*args, **kwargs):
-
for i in range(8):
-
myfunc(*args, **kwargs)
-
return inner_func
В итоге мы получим не что иное как вывод слова spam целых восемь раз. Декораторы как и любые функции могут принимать параметры.
Например
-
def console(text_to_print):
-
def dec(func, *args, **kwargs):
-
print text_to_print
-
func(*args, **kwargs)
-
return dec
-
-
@console("ahtung")
-
def index():
-
print "test"
Выведет сначала ahtung и только потом test.
Пример, если декорируемая функция получает дополнительные аргументы. Взят из пакета pybb, надеюсь автор не против =).
-
def ajax(func):
-
def wrapper(request, *args, **kwargs):
-
if request.method == ‘POST’:
-
try:
-
response = func(request, *args, **kwargs)
-
except Exception, ex:
-
response = {‘error’: traceback.format_exc()}
-
else:
-
response = {‘error’: {‘type’: 403, ‘message’: ‘Accepts only POST request’}}
-
if isinstance(response, dict):
-
return JsonResponse(response)
-
else:
-
return response
-
return wrapper
И пример его использования
-
@ajax
-
def setstatus(request):
-
return {‘newstate’: ‘updated’, ‘date’: ‘2008-08-21’}
Функция может быть задекорирована не только одним декоратором, их может быть несколько.
-
@accepts(int,int)
-
@returns(float)
-
def bar(low,high):
-
pass
Или тоже самое в виде списка
-
[@accepts(int,int), @returns(float)]
-
def bar(low,high):
-
pass
Как оформлять дело каждого, но скорее более читабельным все таки является последовательное декорирование, то есть первый вариант.
Использовал материал и код из
Трека pybb:
http://pybb.org/browser/pybb/util.py
Вики:
http://en.wikipedia.org/wiki/Python_syntax_and_semantics#Decorators
http://ru.wikipedia.org/wiki/Python#.D0.94.D0.B5.D0.BA.D0.BE.D1.80.D0.B0.D1.82.D0.BE.D1.80.D1.8B
Офсайта:
Code completition для django проекта
PyDev поддерживает codecompletition, правда у меня на некоторых машинах так и не удалось заставить его заставить распознать и подключить. Но наверно своя машина ближе.
Описываю как я подключал на своем Mac. По аналогии делается и на Windows машинах.
1. В Preferences эклипса есть раздел PyDev, внутри него таится Interpreter – Python. Что необходимо сделать это указать путь до вашего интерпретатора. Дальше он сам определит какие пакеты находятся в PYTHONPATH.
2. Открываете Preferences своего Django проекта. Чтобы заставить PyDev понимать его исходники как пакеты, достаточно выбрать в PyDev – PYTHONPATH Project Source Folders.
3. Чтобы наверняка в External Source Folders заносим путь до django директории.
Результат вот:
Вышел PyDev 1.3.22
В принципе делаю вынеску из оффсайта. Особенно порадовал 7 пункт.
* Debugger: Pythonpath is the same in debug and regular modes (sys.path[0] is the same directory as the file run)
* Debugger: Choices for paths not found are persisted
* Code-completion: If __all__ is defined with runtime elements (and not only in a single assign statement), it’s ignored for code-completion purposes
* Code-completion: Works on case where imported module has same name of builtin
* Editor: Cursor settings no longer overridden
* Interpreter config: “email” automatically added to the “forced builtins”
* Parser: Correctly recognizing absolute import with 3 or more levels
* Syntax check: Option analyze only active editor
* getpass.getpass: No longer halts when run from pydev (but will show the password being written)
* Remove error markers: Context menu in folders to remove error markers created
Разработка через тестирование глазами новичка
Иногда программисты которые пишут приложения почему то игнорируют написание тестов, а то и вообще их избегают. Я не могу сказать, что я профи в разработке через тестирование, но разработав пару классов и применив их в проекте, уже могу точно сказать, что классы, написанные через тесты обладают наибольшей стабильностью. Конечно, есть еще у меня некоторые недоработки, которые я стараюсь заполнять сразу же.
Практически процесс довольно интересный, хоть и может показаться долгим и утомительным, но как я заметил, когда писал код я вижу слабые участки (а порой ленюсь их исправлять, но позже все таки исправляю), код становится более чистым, особенно, когда отрефакторишь и прогонишь функционал через тесты. А видеть при прогоне слово Ok просто блаженство.
Кстати заметил фишку в разработке тестов в unittest питона. Если в начало теста поставить описание docline то при проходе отобразится не скучный путь до пакета и модуля а полноценное описание теста. К примеру
-
def testSetRatingTwice(self):
-
"Expect raising of exception when user set rating for object twice"
-
# functional of the test
-
self.assertRaises(….)
Ну конечно и отказываться от пакета и модуля не советую, оставить хотя бы название модуля и теста, для того чтобы найти в приложении нужный файл быстрее, чем рыться по полчаса в поисках.
Очень не нравится пакет pymock, который очень часто вводит меня в ступор своими Inappropriate action или чем то подобным, поэтому стараюсь как можно чаще избегать подобных тестов, а то и вообще не прибегать к mock совсем.
Продолжаю процесс разработки через тестирование.
