Что ж, как я писал в комментариях про git, можно ожидать существенного расширения экосистемы mercurial за счет связанных с python проектов. Скорее всего, эффект будет не меньший, чем от перехода Ruby on Rails на git. Теперь надо внимательно следить за Django, SQL Alchemy и pygtk — многое зависит от того, на что перейдут они.

Существует два самых распространенных подхода к описанию ограничений доступа в информационных системах. Первый — нельзя ничего, кроме функций, явно указанных как разрешенные. Второй — можно все, кроме явно запрещенного. Ни один из подходов не является однозначно лучшим, выбирать нужно в зависимости от особенностей конкретной системы. Если оная состоит преимущественно из публичной части, то удобнее описывать политику доступа через ограничения. Если публичная часть мала, а основное взаимодействие происходит с зарегистрированными пользователями — описываем, наоборот, через набор разрешений. Ну и еще имеет значение то, в какую сторону в данной системе страшнее ошибиться — что-то лишнее разрешить или запретить.

Проблема

Какое отношение все это имеет к Django? Наша команда в настоящий момент разрабатывает систему, в которой почти весь функционал предназначен для зарегистрированных пользователей.

В текущем версии фрэймворк не особо помогает нам с описанием прав доступа (да и в 1.1 не обещают улучшений по этой части). А именно – доступен только запретительный механизм описания, осуществляемый через навешивание на view-функции декоратора login_required

Примерно так:

from django.contrib.auth.decorator import login_required

@login_required # Доступ ограничен
def some_view(requests):
   # blah-blah-blah

# Доступ свободный
def other_view(requests):
   # blah-blah-blah

Во всей красе проявляются недостатки такого подхода — нужно вешать декоратор на 90% представлений. Плюс к тому, всегда есть риск получить неочевидную дыру в безопасности системы, если забыть поставить декоратор.

Решение

В рамках стремления к лучшему и концепции “сделай сам” разработан способ описывать права через набор разрешений.

from middleware.security import public

# Доступ ограничен, как если бы стоял login_required
def some_view(requests):
   # blah-blah-blah

@public # Доступ свободный
def other_view(requests):
   # blah-blah-blah

Инструкция по установке

1. Скачиваем модуль security.py и кладем его куда-нибудь. У нас это директория middleware, общая для всех приложений.

2. В настойках добавляем NonpublicMiddleware

   MIDDLEWARE_CLASSES = (
       ...,
       'middleware.security.NonpublicMiddleware', 
   )
   

3. По необходимости правим функцию is_public, чтобы изменить логику определения известных публичных view (сейчас это все, находящееся в пакете django, за исключением django.views.generic)

4. Все, можно пользоваться.

security.py

В связи с повышением спроса со стороны потенциальных заказчиков, мы объявляем набор веб-разработчиков.

Нас 3 человека, находимся в Тольятти, работаем в области аутсорсинга около 5 лет. Клиенты из США, Канады, Европы. Как фирма не оформлены, планируем сделать это в ближайшем будущем. В данный момент нам нужно еще 2-3 разработчика.

Занимаемся разработкой веб-систем на заказ с использованием наиболее современных технологий. На сегодняшний день — Django и Ruby on Rails.

Основные требования

• Общий опыт работы от 2-3 лет

• Опыт веб-разработки, выражающийся в понимании HTTP, HTML, CSS, javascript

• Владение хотя бы 2-мя высокоуровневыми языками программирования

• Хороший письменный английский

Приветствуется

• Python, Ruby

• SQL

• Django, Ruby on Rails

• Опыт работы на *nix-системах

• Опыт написания юнит-тестов, test-driven development

• Опыт использования систем управления версиями и багтреккинга (мы используем Mercurial и Trac соответственно).

Условия

Готовы платить 2000 долларов в месяц подходящему нам человеку, который сможет адекватно встроиться в коллектив, и давать результат на уровне среднего по команде. Тем, кто знает и умеет меньше, чем мы, первое время будем платить меньше. Поднимать по мере обучения тоже будем, целевой уровень все те же 2000. Нижняя граница стартовой суммы находится где-то в районе 1400, меньше подходящий нам кандидат, вероятно, не стоит. Валюта оплаты зависит от конкретного проекта, обычно это доллары США.

Работа дома. Организуете свое рабочее место своими силами и за свой счет.

График свободный в той степени, в которой он не мешает координации работ с коллегами и присутствию на проходищих несколько раз в неделю онлайн-обсуждениях. Допускается работа с меньшей загрузкой в течение испытательного срока.

Тем не менее, мы ожидаем работы на полную ставку, 40 часов в неделю. Формального учета рабочего времени нет, контроллируем по результатам.

Дополнение

Нужно будет 1-2 раза в неделю встречаться лично, поэтому совсем удаленная работа нам не подойдет, нужно чтобы вы находились в Тольятти или окрестностях.

В качестве первого шага присылайте ваше резюме или портфолио.

Со мной можно связаться по почте (me [собака] alexlebedev.com) или ICQ (160365425).

– Александр Лебедев

Давайте разберем ее применительно к сегодняшней реальности.

from module import *

Цитата:

from module import * is invalid inside function definitions.

…

While it is valid to use from module import * at module level it is usually a bad idea. For one, this loses an important property Python otherwise has — you can know where each toplevel name is defined by a simple “search” function in your favorite editor. You also open yourself to trouble in the future, if some module grows additional functions or classes.

…

Remember, you can never know for sure what names a module exports, so either take what you need — from module import name1, name2, or keep them in the module and access on a per-need basis — import module; print module.name.

[оригинал]

Почти согласен.

1. Возможность четко найти в текущем файле откуда взято любое имя действительно ценна.

2. Использование import * рано или поздно приводит к каскадному распространению имен, что значительно затрудняет отладку и снижает логическую изолированность частей программы.

Unadorned exec, execfile() and friends

Цитата:

The word “unadorned” refers to the use without an explicit dictionary, in which case those constructs evaluate code in the current environment. This is dangerous for the same reasons from import * is dangerous — it might step over variables you are counting on and mess up things for the rest of your code. Simply do not do that.

[оригинал]

Полностью согласен.

Кроме того, надо помнить, что оттенки eval всегда опасны, и должны использоваться только если совсем нет других вариантов. При малейшей возможности eval надо менять на getattr/setattr и т.п.

from module import name1, name2

Цитата:

This is a “don’t” which is much weaker then the previous “don’t”s but is still something you should not do if you don’t have good reasons to do that. The reason it is usually bad idea is because you suddenly have an object which lives in two separate namespaces. When the binding in one namespace changes, the binding in the other will not, so there will be a discrepancy between them. This happens when, for example, one module is reloaded, or changes the definition of a function at runtime.

[оригинал]

Да, такая опасность есть. Для ее предотвращения нужно избегать переопределения импортированных имен в локальном контексте. Думаю, что это правило достаточно просто запомнить. Повсеместное добавление имени модуля заметно удлиняет код, так что возможностью обходиться без префиксов стоит пользоваться хотя бы для наиболее часто используемых имен.

except:

Цитата:

Python has the except: clause, which catches all exceptions. Since every error in Python raises an exception, this makes many programming errors look like runtime problems, and hinders the debugging process.

[оригинал]

Полностью согласен, ловля всех исключений без разбора неприемлема. Даже базовый Exception допустимо ловить только тогда, когда ты очень хорошо понимаешь, что делаешь. В подавляющем большинстве случаев задача решается отловом одного-двух более конкретных типов исключений.

Exceptions

Цитата:

Exceptions are a useful feature of Python. You should learn to raise them whenever something unexpected occurs, and catch them only where you can do something about them.

…

So, try to make as few except clauses in your code — those will usually be a catch-all in the main(), or inside calls which should always succeed.

[оригинал]

Полностью согласен, изложены грамотные практики работы с исключениями.

Единственное замечание к этой главе в том, что показана устаревшая практика утилизации ресурсов:

def get_status(file):
    fp = open(file)
    try:
        return fp.readline()
    finally:
        fp.close()

Современный подход предполагает использование with:

def get_status(file):
    with open(file) as fp:
        return fp.readline()

Using the Batteries

Цитата:

Every so often, people seem to be writing stuff in the Python library again, usually poorly. While the occasional module has a poor interface, it is usually much better to use the rich standard library and data types that come with Python then inventing your own.

[оригинал]

Да, изобретение велосипеда никогда не было хорошей идеей.

Между тем, все приведенные в оригинальной статье примеры не очень удачны:

1. Формирование путей через сложение строк вполне допустимо, если всегда использовать прямой слэш, который вполне нормально работает и в Windows.

2. Использование reduce сейчас считается плохой практикой, да и стандартная функция sum давно существует.

Using Backslash to Continue Statements

Цитата:

Since Python treats a newline as a statement terminator, and since statements are often more then is comfortable to put in one line, many people do:

if foo.bar()['first'][0] == baz.quux(1, 2)[5:9] and \
    calculate_number(10, 20) != forbulate(500, 360):
        pass

You should realize that this is dangerous: a stray space after the \ would make this line wrong, and stray spaces are notoriously hard to see in editors.

…

It is usually much better to use the implicit continuation inside parenthesis

[оригинал]

Полностью согласен.

Почти всегда можно воспользоваться скобками для выражений, а также тройными кавычками и автоматическим сложением для строк. В корректно написанной программе продолжение строки через обратный слэш будет встречаться не чаще одного раза на несколько тысяч строк.

дополнение

Вот несколько примеров переноса строк без обратного слэша:

1. Длинный if

   if request.host in self.lastRequestTime and \
       (time.time() - self.lastRequestTime[request.host] < self.throttleDelay):
   

   Меняем на:

   if (request.host in self.lastRequestTime and
       (time.time() - self.lastRequestTime[request.host] < self.throttleDelay)):
   

2. Используем уже имеющиеся скобки

   if internal_id in [str(ch.settings_dict.get('id')) \
       for ch in self.campaign_obj.channel_set.filter(type=channel.type)]:
       raise forms.ValidationError(['You have already subscribed for this %s' % channel.type_name]) 
   

   Меняем на:

   if internal_id in [
       str(ch.settings_dict.get('id'))
       for ch in self.campaign_obj.channel_set.filter(type=channel.type)
       ]:
       raise forms.ValidationError(['You have already subscribed for this %s' % channel.type_name])
   

3. Автоматическре склеиваение строковых переменных

   raw_input("== External authentication\n" +
             "Please open this URI in browser:\n%s\n" +
             "When page finishes loading press any key to continue" % api_client.get_login_uri())
   

   Меняем на:

   raw_input("== External authentication\n"
             "Please open this URI in browser:\n%s\n"
             "When page finishes loading press any key to continue" % api_client.get_login_uri())
   

Спасибо Артему Скорецкому и Анатолию Иванову за участие в обсуждении.

Давно уже стало банальностью утверждение о том, что программисты могут отличаться в производительности в десять и более раз. Среди важнейших причин, наряду с талантом и правильными условиями работы (сюда входит все от процессов разработки и тестирования до зарплаты, атмосферы в коллективе и удобства кресел), фигурирует и использование правильных практик программирования. Кент Бек (Kent Beck), создатель методологии Extreme Programming, говорил о себе “Я не считаю себя замечательным программистом, я лишь неплохой программист с замечательными привычками”. В этой и последующих статьях цикла будут рассмотрены некоторые практики, входящие в мой собственный набор “замечательных привычек”, а также реально полезные инструменты и библиотеки.

В качестве основы взяты практические эпизоды наших текущих проектов. Материал нового цикла будет в первую очередь полезен для разработчиков и, в особенности, для тех-лидов и руководителей, осуществляющих “тренерскую” работу.

Предположим, что вы хотите повысить свою эффективность как программиста. Или, что более интересно, повысить эффективность разработчиков в своей команде. Какое занятие отнимает больше всего времени после непроизводительной активности в составе: кофе, перекуры, bash.org? Наверняка это отладка. Отладка обычно занимает вдвое-втрое больше времени, чем написание первой (не работающей) версии кода.

Сегодня я напишу о способе, который позволит сделать отладку более приятной и эффективной.

Все, за исключением использования графических дебаггеров, способы отладки базируются на текстовом выводе значения переменных. Логи, Exception’ы, консоль — все это требует представления данных программы в текстовом формате. Каждый раз, когда это представление выбрано неудачно, вам придется менять его и проходить еще одну итерацию отладки. Некоторые ошибки будет сложно или совсем невозможно воспроизвести. Следовательно, очень желательно выбрать правильное представление с первого раза.

Сразу предупрежу, что стандартная реализация далеко не идеальна.

Что произойдет при попытке напечатать значение объекта в python?

>>> print 7
7
>>> print range(5)
[0, 1, 2, 3, 4]

Пока все хорошо. Попробуем отойти от базовых типов данных:

class Run(object):
    pass

>>> r = Run()
>>> r.status = 'new'
>>> print r
<__main__.Run object at 0xd3f944c>
>>> print 'Shit happens...'
'Shit happens...'

Отвратительно. Придется обращаться отдельно к каждому атрибуту, что не очень удобно.

Надо сказать, что в Ruby вывод подробного состояния объекта реализован очень правильно:

>> Run.find :first
=> #<Run:0xb725f884 @attributes={"status"=>"done",
"finished_at"=>"1900-01-01 00:00:00", "id"=>"1",
"started_at"=>"1900-01-01 00:00:00"}>

Python здесь явно проигрывает. Впрочем, как я покажу дальше, не все так плохо.

Дело в том, что поведение объекта при вызове print можно настраивать. Для этого служат два специальных метода: __str__ и __repr__ — первый для описания объекта в свободной форме, второй — для максимально строго и полного описания соответственно (желательно, чтобы результат __repr__ являлся валидным выражением на языке python, описывающем текущий объект). Для отладки актуален, преимущественно, метод __repr__.

Классическое исполнение выглядит следующим образом:

class Run(object):
    def __init__(self, status, started_at):
        self.status, self.started_at = status, started_at
    def get_name(self):
        return self.user_name
    def __repr__(self):
        return "Run: status=%s started_at=%s" % (
            self.status, self.started_at)

    >>> from datetime import datetime
    >>> r = Run('new', datetime.today())
    >>> r
    Run: status=new started_at=2007-08-12 03:16:26.468553

В этом коде нарушается принцип DRY (don’t repeat yourself): при добавлении в класс нового атрибута вам придется менять код текстового представления объекта.

В один прекрасный день обнаруживаешь, что у тебя накопилось с десяток классов с 5-15 значимыми атрибутами каждый, а редактирование методов __repr__ достало до печенок. Как быстро выяснилось, есть способ реализовать __repr__ раз и навсегда. Для этого достаточно немного покопаться во внутренней механике объектов, а именно — использовать свойство __dict__, дающее доступ ко всем атрибутам данного объекта в виде dictionary формата “имя: значение”. Такая реализация даже более компактна, чем явная печать каждого атрибута:

class Run(object):    
    # ...
    def __repr__(self):
        return 'Run: %s' % dict([
            (k,v) for k,v in self.__dict__.items() if not k.startswith('_')])

>>> session = create_session()
>>> Run.get_latest(session)
Run: {'status': 'done', 'finished_at': datetime.datetime(2007, 8, 8, 20, 26, 48),
'resume_after': None, 'started_at': datetime.datetime(2007, 8, 8, 20, 26, 42),
'id': 4L, 'errors_in_a_row': 0}

Примечание: здесь и далее в примерах работа с БД организована с помощью библиотеки SQLAlchemy. Это, пожалуй, лучшее что есть сейчас в python для работы с базами данных.

Обратите внимание на выражение dict([(k,v) for k,v in self.__dict__ if not k.startswith('_')]). В pyhton принято начинать имена private-атрибутов с одного подчеркивания (”_”), следовательно, мы отфильтровываем все private-атрибуты и не показываем их. По опыту могу сказать, что это очень удобно при работе с SQLAlchemy, которая добавляет к вашим объектам кучу служебных свойств.

Уже гораздо лучше: написанный один раз код можно просто копировать в каждый новый класс. Для тех, кто работает под девизом “зачем объектное программирование, когда есть блочное копирование” этого вполне достаточно. Мы же пойдем чуть дальше и создадим действительно универсальную реализацию:

class Inspectable(object):
    """Provide an ability to print class instance and its attributes"""
    def __repr__(self):
        return '<%s: %s>' % (
            self.__class__.__name__,
            dict([(x,y) for (x,y) in self.__dict__.items() if not x.startswith('_')])
            )

class Run(Inspectable, object):
    #...

>>> session = create_session()
>>> Run.get_latest(session)
<Run: {'status': 'done', 'finished_at': datetime.datetime(2007, 8, 8, 20, 26, 48),
'resume_after': None, 'started_at': datetime.datetime(2007, 8, 8, 20, 26, 42),
'id': 4L, 'errors_in_a_row': 0}>

Обратите внимание на порядок наследование в Run: Inspectable, object. В python наследование от списка классов резолвится слева направо, поэтому первыми должны быть указаны классы, располагающиеся ниже в иерархии наследования. В противном случае получите ошибку наследования:

>>> class Run(object, Inspectable):
...   pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Error when calling the metaclass bases
    Cannot create a consistent method resolution
order (MRO) for bases object, Inspectable

Кстати, явно наследовать от object совсем необязательно — ведь Inspectable тоже является потомком object. Я, однако, предпочитаю указывать object если перед этим наследую только от абстрактных классов — по идеологии это близко концепции mixin’ов в Ruby.

Точка зрения сотрудника

Очень рекомендую прочитать как статью, так и комментарии. Если кратко, приводятся два основных аргумента:

1. После того, как ты понял и полюбил Python, писать на C# неприятно. Код громоздок и некрасив. Процедурный подход вызывает кучу потенциальных глюков. Кроме того, начав думать на Python, приходится работать “живым компилятором”, переводя эти мысли в C#.

2. Начав использовать функциональное программирование, пытаешься использовать его везде где только можно. C# не поддерживает многие концепции функционального программирования, в результате чего попытки применять функциональный стиль выглядят уродливо и непонятно. Многие задачи проще решать процедурно.

Люк делает вывод, что нет смысла заниматься самосовершенствованием, если потом не сможешь использовать обретенные навыки.

С изменением среды, на самом деле, все плохо. Шансы рядового программиста или проджект-менеджера изменить политику и стандарты компании, как правило, асимптотически приближаются к нулю. Исключения, когда проектная команда обладает высокой степенью автономности и может использовать какие угодно инструменты, редки как девственность.

В свое время это было одним из факторов, побудивших меня покинуть моего предыдущего работодателя и начать работать на себя.

Добавлю еще, что все относительно. Можно заменить языки в обсуждаемом примере на другие, но проблема останется той же. Есть языки лучше, чем Python и Haskell, есть и множество языков, куда хуже C#. В реальной жизни все еще сложнее, потому что важно не столько качество языка, сколько пригодность его и связанной с ним платформы для решения конкретной задачи.

Точка зрения компании

С другой стороны, компания существует не для того, чтобы развлекать сотрудников. Компания существует для того, чтобы получать прибыль. Соответственно, инструменты выбираются в первую очередь по влиянию их использования на прибыль.

Ряд задач требуют использования неоптимальных с точки зрения эстетики и уровня абстракции языков. Драйвера и embedded-приложения пишутся на C. Windows-приложения — на том, что поставляет в данный момент Microsoft (сейчас это C#). SAP кастомизируется с помощью ABAP, недалеко ушедшего в своем развитии от COBOL. Можете продолжать до бесконечности.

Кроме того, есть ниши, где выбор языка может повлиять на маркетинговую привлекательность продукта. Java продается. C# продается. Hashkell… — а что это такое? Думаю, логика выбора языка в таком случае будет очевидна.

Что думаете по этому поводу, коллеги?