vfvnvsyevsky

https://github.com/django-mptt/django-mptt/

Есть хитрый вариант, подходит для вложенных объектов:

>>> x = [u'привет мир']
>>> x
[u'\u043f\u0440\u0438\u0432\u0435\u0442 \u043c\u0438\u0440']
>>> print str(x).decode('unicode-escape')
[u'привет мир']

К сожалению, Питон строки показывает только в строках, а списки и словари будут выдавать такую вот пакость.
Сделайте
'\n'.join(error)
Или
'<br />'.join(error)
в предыдущем вашем вопросе.

>>> s = u'\u041e\u0431'
>>> print(s)
Об

Гугл: https://www.google.ru/webhp?sourceid=chrome-instan...
2 верхних ссылки оттуда:
stackoverflow.com/questions/21882298/django-upload...
stackoverflow.com/questions/13704320/django-upload...

Про request.FILES: https://docs.djangoproject.com/en/1.7/ref/request-...

request.GET.get('next')

Все должно работать. Попробуй посмотреть, что в GET вообще есть (print request.GET).

Для начала: https://www.python.org/dev/peps/pep-0020/
Один из пунктов там "явное лучше неявного".

Views в django на то и придуманы чтобы передавать данные и делать это явно, но то, как это сделать всецело зависит от Вас. Вы правы, нет смысла во всех вьюхах городить огород с передачей одних и тех же данных, тем более, если они общие для большинства шаблонов, но ни custom context processor, ни тем более custom template tag Вас не выручат так, как может одна простая конструкция:

где-нибудь в utils.py

def base_context(request):
    return Context({
        'user': request.user,
        '...': '...',
    })

Где-нибудь в views.py:

def view(request):
    context = base_context(request)
    context['this view specific data'] = 'happy coding'
    return render_to_response('template.html', context)

Таким образом Вы:
1. Не захламляете общий request flow и сохраняете контроль над контекстом любой вьюхи. Context processors будут вызваны для любого рендера, тогда как такой подход позволит Вам всегда иметь минимум необходимых данных под рукой и полный контроль над всеми вьюхами.

2. Передаете в контекст шаблонизатора только, что действительно должно в него попасть. Больше того, в отдельных вьюхах Вы даже можете переопределить базовые параметры, что не так удобно делать с context processors. (но лучше см. п.3)

3. Можете расширить абстракцию как угодно, и создать хоть 2, хоть 3, хоть больше базовых контекстов под всевозожные ситуации (зависит от архитектуры).

Убедитесь что у вас реквест есть в контекст процессорах

TEMPLATE_CONTEXT_PROCESSORS = (
  ...
  'django.core.context_processors.request',
)

И тогда можете прямо в шаблонах писать
{{ request.user.username }}

Если другие данные нужны, то в общем случае надо написать свой context processor или template tag.

В render_to_response надо передовать RequestContext, но проще вместо render_to_response использовать функцию render, в нее нужно передавать request.

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

Прежде чем запускать migrate (он же syncdb, но лучше migrate, а про syncdb забыть), необходимо создать миграции:

python manage.py makemigrations
python manage.py migrate

Вы наверное имели ввиду void* ?
Отличие в том, что id указатель на objective - c объекты, а void* указатель на неопределенный тип, или просто область в памяти (в которой может хранится все что угодно).

stackoverflow.com/questions/1304176/objective-c-di...

$("div#"+theActiveId).hide();

По всей видимости шрифт не успевает подгрузиться. Попробуйте сделать задержку, но это плохой вариант, так как величина задержки будет для разной скорости разная.
Есть еще такой вариант — сделайте блок div с одним символом и спрячьте его, например position:fixed и left:-1000px;
И с интервалом проверяйте его высоту до тех пор, пока она не станет равна заранее измеренной с нужным Вам шрифтом, интервал останавливайте. Когда это произойдет — шрифт загрузился и можно запускать Ваш скрипт.