Спасибо за вопросы! По поводу рантайма — конечно, проседает, но точных замеров я не делал. В моем случае используется метакласс и срабатывает он на 3-4 десятка классов при загрузке приложения.
Проблема в том, что объект параметров должен подстраиваться под каждый класс индивидуально. Т.е. есть у нас класс Foo и объект параметров для него FooKwArgs. Потом мы наследуем от него Bar и добавляем еще пару именованных аргументов в конструктор. Следовательно, делаем новый объект BarKwArgs. Наследовать его от FooKwArgs нельзя, если последний — namedtuple, так что надо делать нечто свое, с магией в __setattr__. А еще бывает diamond inheritance (в моем проекте часто получается), и там нужно быть внимательным.
В общем, вижу много трудозатрат на рефакторинг. Классов у нас около 300 (ветвистое дерево наследования). При описанном подходе я добавляю метакласс в корень дерева, грубо говоря трачу O(1) времени вместо O(N).
По поводу пункта 2. Создайте класс Foo и определите поле self.__bar в __init__(). Создайте foo = Foo() а потом спокойно присвойте foo._Foo__bar любому значению. Все прекрасно работает без всякой интроспекции (кстати, что такое интроспекция в питоне? гм, getattr() с __dict__-ом чтоли?). Так что ничего они не приватные. Приватность — это невозможность изменить поле извне, в т.ч. в дочерних классах. И раз уж об этом зашла речь, окей, в том числе для этого придумали __slots__.
PEP8 это, конечно, здорово, но в реальном мире, в котором написаны к примеру matplotlib, twisted и tornado никто никогда в здравом уме такую свинью с двумя подчеркиваниями разработчикам не подкладывает. Можете привести пример известного, крупного проекта, где «приватные» поля начинаются как пепе?
Что? В какой момент в питоне появились приватные поля? Не вводите людей в заблуждение. Во-первых, в большинстве проектов «приватные» поля принято начинать с одного нижнего подчеркивая, а не с двух. Во-вторых, два нижних подчеркивания стараются использовать только для служебных «магических» методов вроде __len__(). И в-третьих, и те и другие все равно можно изменять, просто с двумя подчеркиваниями добавляется имя класса (что кстати ломает нормальное использование в дочерних классах).
Елки-палки, Яндекс, иди ты в баню со своим «продвинутым» алгоритмом одобрения заявок на участие в конференции и «своевременным» сообщением про правила игры. Наша команда свои сверточные нейронные сети во все корейские телефоны и телевизоры встраивает, но кого это волнует, Research это не для нас…
В ваш лаунчер можно добавить ещё такую платную фишку: в зависимости от координат телефона или времени показывать разные плитки. Обобщая — добавить профили. Как максимум — брать готовые профили из, к примеру, CyanogenMod.
Я имел в виду, что GUI для гита под Windows действительно хорошие только платные. TortoiseGit использовать так проще сразу в консоли команды набирать, будет хотя бы понятнее и надежнее (и в перспективе быстрее). Есть еще гораздо более приятный клиент от Atlassian, его почему-то стало проблематично скачать, но ссылка на старую версию работает. А так у нас все виндузятники сидят на SmartGit.
TortoiseHG когда я им пользовался в последний раз был не в пример удобнее и прозрачнее. Не в курсе, есть ли другие неплохие бесплатные клиенты, подозреваю что есть.
Видимо потому что только в Perforce можно жестко требовать формат commit message (доходит до смешного), запрещать отменять уже созданные, но еще не отправленные правки (вообще полный бред) и создавать каждому программисту по персональному сандбоксу, в которых должна типа вестись реальная разработка. Ну и до кучи запрещать удаление веток и постоянно менять IP адрес сервера.
И в том и другом. Во-первых, канал у нас достаточно узкий (это еще ладно) и с высоким RTT (несколько сотен миллисекунд пинга это ооочень медленно). Во-вторых, сам по себе сервер чертовски медленный (на одной машине тысячи и тысячи пользователей). И в-третьих, корейцы я подозреваю что просто не в курсе таких умных слов как «режим Distributing» в своей маниакальной одержимости запрещать все что только можно. Комит локальный и то отменять запрещают. Я бы долго и смачно ругал их инфраструктуру и описывал причины этого «фрактала отсоса», но боюсь за свой NDA.
Приходилось (и приходится) администрировать на работе порядка сотни репозиториев git и пару-тройку hg. Типичный размер проекта — до 2-3 сотен тысяч строк. Все проекты под Linux. Специфика: околонаучный R&D, много младших программистов. По опыту:
1) В настоящий момент Git работает ощутимо быстрее при работе с удаленной копией. Ради эксперимента конвертировал mercurial проекты в git, время клонирования сокращалось примерно в полтора-два раза. С отправкой правок назад Гит также справлялся быстрее. В связи с этим недоумеваю по поводу бенчмарка скорости контроля версий, проведенным питонистами, когда они решали, где хранить свой Питон.
2) Локальные репы Mercurial периодически тупо портились нахрен. Уже не помню точно симптомы, по-моему hg сегфолтился. Это было бы смешно, если бы не так грустно: джуниоры теряли пару дней своей работы.
К слову, гит репы переживали даже file system corrupton, причем серьезный такой, с перетиранием последних файлов в .git мусором на рейде с ext4. git fsck/git gc/git fetch/git checkout с ручным удалением objects реально работает даже в запущенных случаях с отсутствующими комитами и прочими ударами судьбы.
3) Про «кишки наружу» — согласен. Но в ситуациях, когда «криво намержил/не так отребейзил/наворотил от некомпетентностинезнания полный ахтунг в репе» git reflog спасал бесчисленное число раз. Просто откатывал к последней «точке восстановления» и все. Даже не заикайтесь про hg rollback при неизвестной серии косяков в истории).
4) Из-за своей большей распространенности у Гита все гораздо лучше с интеграцией в CI и шире выбор сервисного софта. Речь не об отсутствии/присутствии плагина в Jenkins, а о количестве настроек и интеграции с другими плагинами. Одних Git веб серверов столько, что не сосчитаешь. Любая ревью система умеет гит, но не всегда — mercurial. Просмотрщиков истории изменений у гита пруд пруди, для меркуриала в свое время еле выбрал. Реализаций клиента у гита есть как минимум два — С и Java (JGit), и это очень круто, так как куча серверов на Java умеют гит нативно.
Огромный плюс Mercurial — хорошая поддержка Windows. Вынужден признать, что у гита по-прежнему бесплатно с этим не очень.
Благодаря тому, что сервер VD подразделения Самсунга находится в штаб квартире, банальная загрузка очередной телевизионной прошивки в России длится несколько дней. Я уж молчу про отсылку изменений назад, когда создается по два соединения с сервером на каждый измененный файл… Думаю, мой случай далеко не единичный для географически распределенных команд.
Спасибо! Я ошибся и стал грешить на fork, в то время как суть была не в нём, а в демонизации. Во всех учебниках пишут, что нужно в демоне закрывать дескрипторы. Даже PEP это утверждает (и делает, как выяснилось).
Проблема, всё же, в urandom, собсно сами разрабы об этом писали. Два раза)
10 из 10 :) Плюс начиная с критической массы кода даже у крутых программистов начинают сыпаться дурацкие опечатки.
Питон — динамический язык, и многие вещи нужно делать руками, например, проверять типы в сеттерах. Зато очень гибкий.
Проблема в том, что объект параметров должен подстраиваться под каждый класс индивидуально. Т.е. есть у нас класс Foo и объект параметров для него FooKwArgs. Потом мы наследуем от него Bar и добавляем еще пару именованных аргументов в конструктор. Следовательно, делаем новый объект BarKwArgs. Наследовать его от FooKwArgs нельзя, если последний — namedtuple, так что надо делать нечто свое, с магией в __setattr__. А еще бывает diamond inheritance (в моем проекте часто получается), и там нужно быть внимательным.
В общем, вижу много трудозатрат на рефакторинг. Классов у нас около 300 (ветвистое дерево наследования). При описанном подходе я добавляю метакласс в корень дерева, грубо говоря трачу O(1) времени вместо O(N).
Ухудшает читаемость :(
И еще нужно что-то параллельно решать с наследованием.
PEP8 это, конечно, здорово, но в реальном мире, в котором написаны к примеру matplotlib, twisted и tornado никто никогда в здравом уме такую свинью с двумя подчеркиваниями разработчикам не подкладывает. Можете привести пример известного, крупного проекта, где «приватные» поля начинаются как пепе?
TortoiseHG когда я им пользовался в последний раз был не в пример удобнее и прозрачнее. Не в курсе, есть ли другие неплохие бесплатные клиенты, подозреваю что есть.
1) В настоящий момент Git работает ощутимо быстрее при работе с удаленной копией. Ради эксперимента конвертировал mercurial проекты в git, время клонирования сокращалось примерно в полтора-два раза. С отправкой правок назад Гит также справлялся быстрее. В связи с этим недоумеваю по поводу бенчмарка скорости контроля версий, проведенным питонистами, когда они решали, где хранить свой Питон.
2) Локальные репы Mercurial периодически тупо портились нахрен. Уже не помню точно симптомы, по-моему hg сегфолтился. Это было бы смешно, если бы не так грустно: джуниоры теряли пару дней своей работы.
К слову, гит репы переживали даже file system corrupton, причем серьезный такой, с перетиранием последних файлов в .git мусором на рейде с ext4. git fsck/git gc/git fetch/git checkout с ручным удалением objects реально работает даже в запущенных случаях с отсутствующими комитами и прочими ударами судьбы.
3) Про «кишки наружу» — согласен. Но в ситуациях, когда «криво намержил/не так отребейзил/наворотил от
некомпетентностинезнания полный ахтунг в репе» git reflog спасал бесчисленное число раз. Просто откатывал к последней «точке восстановления» и все. Даже не заикайтесь про hg rollback при неизвестной серии косяков в истории).4) Из-за своей большей распространенности у Гита все гораздо лучше с интеграцией в CI и шире выбор сервисного софта. Речь не об отсутствии/присутствии плагина в Jenkins, а о количестве настроек и интеграции с другими плагинами. Одних Git веб серверов столько, что не сосчитаешь. Любая ревью система умеет гит, но не всегда — mercurial. Просмотрщиков истории изменений у гита пруд пруди, для меркуриала в свое время еле выбрал. Реализаций клиента у гита есть как минимум два — С и Java (JGit), и это очень круто, так как куча серверов на Java умеют гит нативно.
Огромный плюс Mercurial — хорошая поддержка Windows. Вынужден признать, что у гита по-прежнему бесплатно с этим не очень.
Проблема, всё же, в urandom, собсно сами разрабы об этом писали. Два раза)