Это не решит проблему, поскольку драйвера как пишут вендоры, так и будут это делать. А баги, как были в драйверах, так там и будут оставаться. ОС — это следующий уровень на драйверами. На уровне ОС конечно можно попытаться исправить поведение драйвера, но тогда эти фиксы придется тянуть в апстрим ОС для всех остальных. В общем, я не совсем понимаю, как обновления ОС отдельно от драйверов решит проблему багов внутри самих драйверов, но вполне возможно, что у меня нет всей информации для таких выводов)
Еще раз) Один из ключевых моментов популярности системы — это как можно меньшее количество камней преткновения для вендоров -> много вендоров -> много аппаратов -> популярность. Это, конечно, не единственный фактор, но один из ключевых. Я опускаю вопрос, насколько качественно каждый вендор подходит к созданию своей продукции. Да и Гугла нет ни времени, ни денег, ни особого желания проверять это у каждого вендора, в том числе и качество дров. Сегодня вендоров 100, завтра будет 110, и каждый раз Гуглу нужно договариваться и проверять, что все заявленное работает по спецификации. А завтра выйдет новая линейка смартфонов с новыми чипами, и все надо делать по новой. Проще, быстрее и финансово менее затратно сделать это один раз в нескольких продуктах. Тем более, что база фиксов может шариться между продуктами. Предлагаю вам подумать, почему до сих пор Гугл не поступил так, как предлагаете вы, а делает так, о чем пишу я. Это не потому, что корпорация такая злая, делает кучу костылей или разрабы и менеджеры ленивые. Просто так эффективнее, дешевле. Вопрос только денег
Я думаю, что тут важнее распространенность системы, чем война с вендорами за чистоту драйверов и прочее. Тут даже скорее обратная ситуация: чем больше смартфонов с андроид, тем он популярнее, тем больше выгоды получит компания. Поэтому в финансовом эквиваленте ставить палки в колеса вендорам для Гугла менее прибыльно, чем запилить фиксы в кодовую базу Хромиума. Ну и по ресурсам первое на порядки затратнее, чем второе. Увы, это реальность
Виндовс — проприетарное ПО, его можно только кастомизировать. Менять исходный код нельзя. Андроид — ос с открытым исходным кодом. Любой вендор может что угодно в ней поменять. В том числе и убрать проверку подписанных драйверов. Вдобавок, видела как правило устанавливается на любое железо, драйвера идут отдельно. С Андроидом — только то, что сделал вендор. Так с Андроидом не выйдет, как на
Ну это бабушка надвое сказала. Процент по вкладам в долларах как минимум в 2 раза ниже, чем в рублях. Тут считать надо, я бы не стал так однозначно утверждать. Если же вы имеете ввиду вклады за рубежом, то тут ничего утверждать не берусь.
Мне кажется, что прецедентов не так много, чтобы ради этого уходить из юрисдикции РФ. Переоформление юр. лица требует времени и денег, может и несущественных, но все же. А профита по сути немного, зато проблем может быть ещё больше. Переход в другую юрисдикцию ведь подразумевает, что удовлетворять требованиям органов больше не надо, а это с большой вероятностью повлечет за собой блокировку, а это — потеря хоть и незначительной, но все же аудитории, да и вполне возможно ещё куча нюансов. В общем, как мне кажется, на данном этапе игра свечь не стоит.
Потому что это не главное)) Главное — как замечательно, что есть такой день, что его поведению обязаны разработчикам из ЕПАМ и что в году появилисся ещё один день, когда можно побухать с коллегами по цеху) Все остальное — вторично)))
Да перестаньте. Дело тут скорее в желании. Квартиры в новостройках сейчас по площади все же больше, чем строили ранее. А уж кухня как правило сравни с комнатой по метражу. И я не верю, что в такой вот квартире на кухне нельзя поставить 4 средних по размеру ведра под ту же раковину. Повторюсь, вопрос лишь в желании. Другой момент, все это не имеет смысла, если это раздельный мусор тупо некуда нести, потому что во дворе стоит один большой контейнер для всего и ничего другого рядом нет.
> Ещё лучше тратить время на исправление действительно значимых проблем
Ну вам виднее) Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы. Желаю успеха вашим продуктам)
Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает. Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю. Чего и вам желаю
Ну что я могу сказать) Если вам приходится писать кучу тестов на такие вот проверки, ну значит Питон не для вас) Используйте статически типизированные языки. А мы просто тесты не пишем на такие вот вещи типа некорректных параметров, подразумевая, что данные корректны, и пока вроде проблем не возникало) Функциональные тесты решают) Зато разработка и поддержка раза в 2 точно меньше времени занимает. А меньше времени на поддержку и разработку — больше фичей, меньше затрат для компании и так далее. В общем, у нас одни плюсы. Если у вас минусы, ну, значит Питон в вашем случае не подойдет.
Ну что поделаешь. Лучше написать один-два лишних теста, чем писать несколько интерфейсов, продумывать правильную цепочку наследования, может даже создавать новые типы для унификации, как-то это все связать вместе и потом поддерживать.
Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных), когда у функции четко описан интерфейс в той же документации, на моей практике возникает нечасто. Разве что по ошибке в вызываемом коде или по злому умыслу. В обоих случаях ловится функциональными тестами. Ну и если что, IDE подскажет, что тут тип не совсем правильный, а если IDE не подскажет, есть typing (https://docs.python.org/3/library/typing.html) и аннотации, тогда уж хороший линтер неправильный тип не пропустит. В общем, все решаемо в Питоне, на любой вкус и цвет, даже с динамической типизацией.
В питоне интерфейсы — это номинальный тип, реально такого типа нет.
> Ну да, сигнатура же описана в интерфейсе
А ещё там есть магические методы типа __getattr__, который спокойно может вернуть этот метод, хотя в интерфейсе класса его нет явно. А ещё в питоне есть возможность в рантайме добавить метод в объект. Поэтому увы, но тут никак интерфейсами не поможешь. Да они особо и не нужны. Как я уже писал, все покрывается тестами. А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов
Теперь я понимаю, о чем вы. К сожалению или к счастью, такой тайпчекинг в языках с динамической типизацией невозможен. И, если честно, я не вижу особой необходимости для этого просто потому, что автоматические тесты являются обязательными. А они в свою очередь покрывают и ту ситуацию, когда объект может использоваться неверно, либо не тот интерфейс у переданного объекта. Ну так просто получается, потому что, тестируя функционал, автоматически тестируются и функции, которые принимают динамически сформированные объекты. А как работать без тестов вообще даже в языках со статической типизацией, я плохо представляю. Программа без тестов, как модульных, так и функциональных, с большой долей вероятности не выдержит даже минимальный рефакторинг без дополнительных затрат на ручные проверки.
Ну хорошо) Простой пример из практики, чтобы вы поняли, что тайпчекинг смысла не имеет. У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value,. к примеру, который не принимает параметров и возвращает число. Функция знает сигнатуру вызываемого метода и знает как с ним работать. Зачем ей тип объекта? Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом. Как это будете тестировать? С каким типом?
Ну наличие где-то в каком то проекте таких тестов совсем не означает, что это common practice. Тесты пишут обычно на функционал, а тесты на поверку типов бессмысленны просто потому, что в питоне обычно используется подход к объектам по "интерфейсу", а не по типу. А тип может быть любой, если он реализует этот интерфейс
Виндовс — проприетарное ПО, его можно только кастомизировать. Менять исходный код нельзя. Андроид — ос с открытым исходным кодом. Любой вендор может что угодно в ней поменять. В том числе и убрать проверку подписанных драйверов. Вдобавок, видела как правило устанавливается на любое железо, драйвера идут отдельно. С Андроидом — только то, что сделал вендор. Так с Андроидом не выйдет, как на
Баги в драйверах, а не в самой операционке. Драйверы Гугл не пишет, по этой же причине доставить их на может на конечное устройство при всем
Ну это бабушка надвое сказала. Процент по вкладам в долларах как минимум в 2 раза ниже, чем в рублях. Тут считать надо, я бы не стал так однозначно утверждать. Если же вы имеете ввиду вклады за рубежом, то тут ничего утверждать не берусь.
Мне кажется, что прецедентов не так много, чтобы ради этого уходить из юрисдикции РФ. Переоформление юр. лица требует времени и денег, может и несущественных, но все же. А профита по сути немного, зато проблем может быть ещё больше. Переход в другую юрисдикцию ведь подразумевает, что удовлетворять требованиям органов больше не надо, а это с большой вероятностью повлечет за собой блокировку, а это — потеря хоть и незначительной, но все же аудитории, да и вполне возможно ещё куча нюансов. В общем, как мне кажется, на данном этапе игра свечь не стоит.
А какая версия совместима с железом?) Где то в спецификации или мануале список есть?
Потому что это не главное)) Главное — как замечательно, что есть такой день, что его поведению обязаны разработчикам из ЕПАМ и что в году появилисся ещё один день, когда можно побухать с коллегами по цеху) Все остальное — вторично)))
Мы сами живёт в одной такой новостройке, на кухне места навалом.
Да перестаньте. Дело тут скорее в желании. Квартиры в новостройках сейчас по площади все же больше, чем строили ранее. А уж кухня как правило сравни с комнатой по метражу. И я не верю, что в такой вот квартире на кухне нельзя поставить 4 средних по размеру ведра под ту же раковину. Повторюсь, вопрос лишь в желании. Другой момент, все это не имеет смысла, если это раздельный мусор тупо некуда нести, потому что во дворе стоит один большой контейнер для всего и ничего другого рядом нет.
Ну вам виднее) Пусть лучше программа крашится или достает пользователей багами в логике, но зато все входные типы там четко протестированы. Желаю успеха вашим продуктам)
Нас это мифическое "полным полно ошибок", о котором вы пишете, вполне устраивает. Лучше потратить время на исправление действительно значимых проблем, чем ситуации, вероятность появления которой стремится к нулю. Чего и вам желаю
Ну и справедливости ради, ситуация, когда в функцию отправляется объект неправильного типа (кроме None, undefined, null и подобных), когда у функции четко описан интерфейс в той же документации, на моей практике возникает нечасто. Разве что по ошибке в вызываемом коде или по злому умыслу. В обоих случаях ловится функциональными тестами. Ну и если что, IDE подскажет, что тут тип не совсем правильный, а если IDE не подскажет, есть typing (https://docs.python.org/3/library/typing.html) и аннотации, тогда уж хороший линтер неправильный тип не пропустит. В общем, все решаемо в Питоне, на любой вкус и цвет, даже с динамической типизацией.
> Ну да, сигнатура же описана в интерфейсе
А ещё там есть магические методы типа __getattr__, который спокойно может вернуть этот метод, хотя в интерфейсе класса его нет явно. А ещё в питоне есть возможность в рантайме добавить метод в объект. Поэтому увы, но тут никак интерфейсами не поможешь. Да они особо и не нужны. Как я уже писал, все покрывается тестами. А если есть веррятность получения неправильного объекта, ловите эксепшн и обрабатываете соотв. образом, или делаете проверку нужных атрибутов
Теперь я понимаю, о чем вы. К сожалению или к счастью, такой тайпчекинг в языках с динамической типизацией невозможен. И, если честно, я не вижу особой необходимости для этого просто потому, что автоматические тесты являются обязательными. А они в свою очередь покрывают и ту ситуацию, когда объект может использоваться неверно, либо не тот интерфейс у переданного объекта. Ну так просто получается, потому что, тестируя функционал, автоматически тестируются и функции, которые принимают динамически сформированные объекты. А как работать без тестов вообще даже в языках со статической типизацией, я плохо представляю. Программа без тестов, как модульных, так и функциональных, с большой долей вероятности не выдержит даже минимальный рефакторинг без дополнительных затрат на ручные проверки.
Ну хорошо) Простой пример из практики, чтобы вы поняли, что тайпчекинг смысла не имеет. У вас есть утилитарная функция, которая принимает объект, у которого должен быть метод get_value,. к примеру, который не принимает параметров и возвращает число. Функция знает сигнатуру вызываемого метода и знает как с ним работать. Зачем ей тип объекта? Ну и этот метод реализуют 20 классов в проекте, которые никак не связаны друг с другом. Как это будете тестировать? С каким типом?
Ну наличие где-то в каком то проекте таких тестов совсем не означает, что это common practice. Тесты пишут обычно на функционал, а тесты на поверку типов бессмысленны просто потому, что в питоне обычно используется подход к объектам по "интерфейсу", а не по типу. А тип может быть любой, если он реализует этот интерфейс