После поисков редактора питоновских скриптов я прошустил довольно много, спрашивал, читал, изучал. Мне не нужен был ни Eclipse ни IDEA. Для моего домашнего ноута честно признатся таких монстров вообще не нужно.
В итоге остановился на emacs. Сейчас читаю классную статью, которую, если вы так же как и я решили перейти на emacs, можете прочитать вот
Кстати под Mac OS X есть отличная обертка над emacs Aquamacs
Разместил: Виталий Волков в 12:04 Апрель 19, 2009. Комментарии выключены
Рубрики: Познание нового, Полезное. Теги: emacs, python.
Христос Воскрес!
Воистину все постигается в чтении умных книг. Буквально недавно сообразил, какую возможно грубейшую ошибку мы совершили в создании одного приложения на Python. Мы использовали для вызова методов родительского класса super.
Пример:
-
class B:
-
-
def __init__(x, y):
-
self.x = x
-
self.y = y
-
-
def setX(x):
-
self.x = x
-
-
-
class A(B):
-
def __init__(x, y, r):
-
super(A, self).__init__(x, y)
-
self.r = r
-
-
def setX(x):
-
super(A, self).setX(x + self.r)
А теперь посмотрим как было бы правильнее
-
class B:
-
-
def __init__(self, x, y):
-
self.x = x
-
self.y = y
-
-
def setX(self, x):
-
self.x = x
-
-
-
class A(B):
-
def __init__(self, x, y, r):
-
B.__init__(self, x, y)
-
self.r = r
-
-
def setX(self, x):
-
B.setX(self, x + self.r)
Разместил: Виталий Волков в 10:04 Апрель 19, 2009. Комментарии выключены
Рубрики: Познание нового. Теги: python, наследование.
Заметил что hasattr в коей мере некорректно работает на определение наличия аттрибута в классе, пришлось отказаться от него и использовать такую проверку
-
if "value" not in MyClass.__dict__:
-
pass
Какие минусы этого подхода полностью не знаю, но знаю что может привести в определенных ситуациях к зацикливанию, это в случае если использовать __setattr__ в паре с ним. Может у кого-то другие подходы? Или просвятит на предмет использования __dict__ :-)
Разместил: Виталий Волков в 15:02 Февраль 4, 2009. Комментарии выключены
Рубрики: Познание нового. Теги: python.
Иногда программисты которые пишут приложения почему то игнорируют написание тестов, а то и вообще их избегают. Я не могу сказать, что я профи в разработке через тестирование, но разработав пару классов и применив их в проекте, уже могу точно сказать, что классы, написанные через тесты обладают наибольшей стабильностью. Конечно, есть еще у меня некоторые недоработки, которые я стараюсь заполнять сразу же.
Практически процесс довольно интересный, хоть и может показаться долгим и утомительным, но как я заметил, когда писал код я вижу слабые участки (а порой ленюсь их исправлять, но позже все таки исправляю), код становится более чистым, особенно, когда отрефакторишь и прогонишь функционал через тесты. А видеть при прогоне слово 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 совсем.
Продолжаю процесс разработки через тестирование.
Разместил: Виталий Волков в 21:10 Октябрь 17, 2008. Комментарии выключены
Рубрики: Познание нового, Полезное. Теги: docline, python, unittest, разработка, тестирование.
Всем снова привет. Как это ни странно сейчас все мое внимание уделено исключительно разработке приложений основанных на web framework Django. Причиной перехода на django является разработке и ведению нового проекта, который наша компания делает для украинской компании. Надеюсь что мы выиграем с этим проектом.
Но это всего лишь отступление. Важной частью разработки является кастомизация некоторых элементов любого сайта использующих какой-бы то ни было фреймворк. Будь то Smarty, Zend Framework, Symphony. Без разницы, все они предоставляют строгий набор элементов, которые используются в проекте. А что делать если нас не устраивает этот набор и необходимо пополнить его своими причиндалами.
В django 1.0 были сделаны некоторые очень полезные добавления, которых я ждал. Введение save_model метода в ModelAdmin класс избавило от написания менеджеров. Что же дает нам ModelAdmin для кастомизации полей?
Любой вам даст совет рыть исходники Django, и что собственно и было сделано. В ModelAdmin есть метод get_form который вернет экземпляр класса формы которая используется в административном интерфейсе. А что если переопределить эту функцию? Выйдет примерно следующее
-
class MyModelAdmin(admin.ModelAdmin):
-
list_display = (‘title’, ‘latin_title’, ‘recipe’)
-
prepopulated_fields = {"url": ("latin_title", )}
-
-
form = MyModelAdminForm
-
-
def get_form(self, request, obj=None, **kwargs):
-
form = super(MyModelAdmin, self).get_form(request, obj=None, **kwargs)
-
-
form.base_fields[‘custom’].widget = MyWidget(obj)
-
return form
-
-
admin.site.register(Medicine, MedicineAdmin)
То что доктор прописал, не так ли? Данного подхода в документации я не нашел, зато на сайте http://djangosnippets.org есть отличный пример, который использует подобную технику.
Разместил: Виталий Волков в 18:09 Сентябрь 5, 2008. Комментарии выключены
Рубрики: Познание нового. Теги: django, python, кастомизация полей.
Я всегда считал, что самый лучший web сервер это apache, я периодически обновлял его, а после определенного момента apache стал подводить. Может потому что я на данный момент работаю на Mac OS X, либо может я стал сам откровенно тупить. Но факт остается фактом, при обновлении PHP связка PHP+Apache перестала работать.
Альтернативные решения:
1. nginx
2. lighttpd
С nginx для меня оказалось все очень сложно, он хорош для продакшн серверов, но не для обыденного разработчика. Поэтому на замену индейцу пришел lighttpd. На Mac OS X он у меня поднялся без проблем.
Единственное, что пришлось немного погуглить на тему как стартовать его автоматически при запуске операционной системы. Ну и только потом перекомпилил PHP c поддержкой FastCGI и немного изменил конфиг веб-сервера, чтобы он корректно обрабатывал скрипты.
Разместил: Виталий Волков в 18:06 Июнь 27, 2008. Комментарии выключены
Рубрики: Познание нового. Теги: apache, lighttpd, nginx, webserver.