Никита Чуков

Сейчас я проясню ситуацию=).
Текст бывает либо в какой-то кодировке (cp1251, utf-8, win866, ascii, и т.д.), тогда это байты; либо в юникоде (это, как бы, абстрактное представление символов), тогда это строки из абстрактных юникодовых символов.
Все файлы, потоки ввода-вывода и т.д. у нас в компьютере работает с байтами, а не с абстрактными юникодовыми символами. Это значит, что перед выводом в файл или консоль должно производиться кодирование юникода в конкретную кодировку.

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

Так, например, кодировка ascii поддерживает только стандартные 128 символов и при попытке конвертировать в неё (явно или неявно) букву "Ж", будет такая же ошибка как у вас. Надо полагать метод parse в вашем случае возвращает юникод, а оператор print делает неявное преобразование в кодировку по умолчанию (ascii, судя по сообщению об ошибке).
Осталось выяснить в каких случаях как определяется кодировка по умолчанию.
Артём Клименко правильно предложил в своём ответе проверить что берётся в качестве кодировки по умолчанию в том и другом случае.
Однако решением проблемы должно быть явное преобразование текста в нужную кодировку. Я в таких случаях придерживаюсь следующих правил:

• Всё, что приходит в программу, привожу в юникод (если это не произошло неявно в той библиотеке, посредством которой я получил данные).
  
• В программе работаю с текстом только в юникоде (если речь не идёт о каких-то низкоуровневых операциях над байтами, вроде парсинга протоколов и прочего.
  
• Перед выводом конвертирую текст в нужную кодировку или настраиваю потоки вывода на автоматическое преобразование.
  
• Когда не понятно в какой кодировке делать вывод, руководствуюсь следующими правилами:
  • Выходной поток -- это виндовый stdout и в нём не задана кодировка (bat-файлы, консоль) -- cp866
    
  • Файлы, БД и прочее, что поддерживает юникод и сделано правильно -- UTF-8
    
  • Когда в винде не помогают пердыдущие пункты -- cp1251
    
  • В других операционках utf-8.
    
  
  

Подчеркиваю. Если выходной поток сконфигурирован на ascii, а у нас в программе могут попасться не-ascii символы, то нужно приводить текст в какую-то кодировку (см выше)), а иначе ничего не трогаем и пишем юникод.

поведение не странное, поведение првавильное

можете прорделать то же в IDLE, увидиите, что там все ок,
но на этот ОК нельзя полагаться: будете забывать о перекодировке и проверке кодировки, когда это необходимо

проделайте то же в консоли (не в IDLE) и там уже будет не ОК

рецепт: не выводите в консоль, пишите в файл или в базу, все будет работать

сталкивался с подобным, и тут не столько пайчарм виноват, вопрос в том в какой кодировке выводится информация, если консоль для вывлда на текущий момент не юникодовая, тут и начинаются такие проблемы.
гляньте что вам вернёт:

import sys, locale, os, codecs 
print(sys.stdout.encoding)
print(sys.stdout.isatty())
print(locale.getpreferredencoding())
print(sys.getfilesystemencoding())

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

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

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

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

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

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

FreeBSD - маршрутизация/DNS/VPN/Samba (старые железки)
2003 Server - сервер терминалов/SQL (Xeon`ы и куча памяти + SAS + RAID)
Debian/FreeBSD - удаленные хосты для WWW/sFTP/VPN

Вообще лучше бы свалить к другому хостеру =) Который не страдает такой фигней.

А по сабжу - проверить, что админы не имеют доступа к машине (нет лишних ssh-ключей, сменен пароль). Убрать прокси за iptables.
Ну и проверить, что у вас вообще Xen, а не openvz. Снаружи виртуалки Xen админ не должен видеть, что у вас в ней запущено. Только по ssh/сканированием по сети.

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