Вы же наверное понимаете почему в питоне целое число занимает 24 байта и более? Вот простейший для питона код, который объясняет это (** — это возведение в степень):
print(10**5000 + 23**1200 — 67**150)
Для питона такие большие ЦЕЛЫЕ числа — не проблема. Поэтому они занимают столько много места.
Интересно сколько времени займёт написать на C аналогичный пример?
Давно слышу эти слухи, про то что compose на Go переписали, но «воз и ныне там».
Единственное что случилось — Swarm mode в докере научили понимать yaml файлы от docker-compose.
Сейчас же разработчики docker переписали утилиту на go
А вы в исходники на том самом гитхабе заглядывали? Я вот что-то беглым осмотром не нашёл ничего там про Go, зато там полно питонячих файлов.
Скорее всего те бинарники, которые у них лежат в релизах — это, «запакованный» в один исполняемый файл, Python со всем нужным для запуска docker-compose.
Переменная, которую вы указали на «уровне» класса — это поле класса (класс ведь тоже объект в питоне), а не экземпляра этого класса. Экземпляр класса может иметь свою «версию» этой переменной, которая появится после первого же присвоения (self.arr = []) в любом методе класса (рекомендуется это делать в методе __init__). Если у экземпляра класса нет своей «версии» переменной, то при попытке «прочитать» её, будет использована «версия» из класса.
Поэтому для «полей» класса действует такая же рекомендация, что и для аргументов функций со значением по умолчанию — не надо использовать изменяемые типы.
Всё на самом деле просто. Сервер, между отдельными запросами, не хранит какого либо контекста (состояния) в котором находится клиент и какие запросы до этого он выполнял.
Примером системы, которая хранит состояние может быть например «помощник» с голосовым интерфейсом (Google Now например). Для такой системы нет ничего необычного в такой последовательности запросов:
1. Какая температура в Москве?
2. А в Самаре?
Тут видно, что «сервер» должен для выполнения второго запроса помнить, что перед этим клиент спрашивал про температуру.
В случае же REST запросы должны быть такими:
1. Какая температура в Москве?
2. Какая температура в Самаре?
Тут сервер ничего не помнит про предыдущие запросы и каждый новый запрос выполнят без оглядки на предыдущие, т.к. все необходимые для выполнения данные находятся в текущем запросе. Такой подход позволяет легче масштабировать систему, т.к. нет необходимости, что бы все запросы клиента обрабатывались только одним или несколькими серверами, у которых есть доступ к хранилищу «состоянию» клиента.
Сравнивать Docker и gunicorn — это как тёплое с мягким. Они не заменяют друг друга. Использование Docker или Vagrant не избавляет вас от необходимости запустить Django-проект в каком либо production ready веб-сервере (gunicorn, uwsgi и др.)
Я тесты пишу в файле tests.py в том же пакете, который тестируется. Если тестов много и их можно сгруппировать, то создаю пакет tests внутри тестируемого пакета, и уже в нём модули test_foo.py, test_bar.py и т.д. В общем я держу тесты ближе «к телу». Если где то можно обойтись маленьким doc-тестом внутри кода, то я так и делаю.
У меня аналогичная задача. Постараюсь описать её понятнее.
Имеется некая система состоящая из нескольких приложений (веб-приложение, менеджер фоновых задач, какой нибудь асинхронный нотификатор на веб-сокетах и т.д.). Требуется работать с этой системой имея только права обычного пользователя. Для этого нужно, что бы пользователь мог запускать/останавливать любые процессы, добавлять/редактировать/удалять список запускаемых процессов.
Именно эти хотелки хорошо решал supervisor. Достаточно было один раз настроить из под root-а авто-запуск под указанным пользователем отдельного процесса supervisord, конфигурация которого доступна для редактирования пользователю.
Если в systemd есть аналогичные возможности, тогда действительно — supervisor «больше не нужен».
print(10**5000 + 23**1200 — 67**150)
Для питона такие большие ЦЕЛЫЕ числа — не проблема. Поэтому они занимают столько много места.
Интересно сколько времени займёт написать на C аналогичный пример?
Единственное что случилось — Swarm mode в докере научили понимать yaml файлы от docker-compose.
А вы в исходники на том самом гитхабе заглядывали? Я вот что-то беглым осмотром не нашёл ничего там про Go, зато там полно питонячих файлов.
Скорее всего те бинарники, которые у них лежат в релизах — это, «запакованный» в один исполняемый файл, Python со всем нужным для запуска docker-compose.
Поэтому для «полей» класса действует такая же рекомендация, что и для аргументов функций со значением по умолчанию — не надо использовать изменяемые типы.
Примером системы, которая хранит состояние может быть например «помощник» с голосовым интерфейсом (Google Now например). Для такой системы нет ничего необычного в такой последовательности запросов:
1. Какая температура в Москве?
2. А в Самаре?
Тут видно, что «сервер» должен для выполнения второго запроса помнить, что перед этим клиент спрашивал про температуру.
В случае же REST запросы должны быть такими:
1. Какая температура в Москве?
2. Какая температура в Самаре?
Тут сервер ничего не помнит про предыдущие запросы и каждый новый запрос выполнят без оглядки на предыдущие, т.к. все необходимые для выполнения данные находятся в текущем запросе. Такой подход позволяет легче масштабировать систему, т.к. нет необходимости, что бы все запросы клиента обрабатывались только одним или несколькими серверами, у которых есть доступ к хранилищу «состоянию» клиента.
Имеется некая система состоящая из нескольких приложений (веб-приложение, менеджер фоновых задач, какой нибудь асинхронный нотификатор на веб-сокетах и т.д.). Требуется работать с этой системой имея только права обычного пользователя. Для этого нужно, что бы пользователь мог запускать/останавливать любые процессы, добавлять/редактировать/удалять список запускаемых процессов.
Именно эти хотелки хорошо решал supervisor. Достаточно было один раз настроить из под root-а авто-запуск под указанным пользователем отдельного процесса supervisord, конфигурация которого доступна для редактирования пользователю.
Если в systemd есть аналогичные возможности, тогда действительно — supervisor «больше не нужен».