Как правильно готовить Python для энтерпрайз - боюсь, что ответ не вместить в комментарий или даже статью. Если очень коротко, то ответ общий для всех ЯП:
голова на плечах
знание ЯП и предметной области
правильное использование нужного инструментария (линтеры, статические анализаторы, и прочее)
хорошее покрытие тестами (для Python, как и для любого другого динамического ЯП нужно очень хорошее покрытие)
опыт
???
Мой опыт говорит о том, что сложную бизнес логику реализовать на Python можно. Так же, при грамотном подходе, можно легко или относительно легко менять её при изменившихся бизнес-требованиях (иногда при кардинально изменившихся).
Python не идеальный язык, у него куча недостатков, производительность - это явно не его (но есть нюансы), динамическая природа привносит много своих неприятностей, однако сфера его применения очень обширная. В корпоративной среде он распространяется очень широко, нравится это или нет.
Опыт мне подсказывает, что для работы с данными используется очень малая часть возможностей Python, как ЯП, потому что в этой сфере важно знание принципов работы с данными и соответствующих бибилиотек. Нюансы и глубокое понимание языка тут не так важно. С исследованиями скорее та же ситуация, если понимать под этим одноразовые Jupyter ноутбуки или скрипты.
В bloody enterprise всё-таки используется немного другой Python (если это не data, ML или AI. Но и тут есть простор для деятельности) со всеми своими достоинствами и недостатками. Бывают, конечно и исключения, особенно когда опытные разработчики вынуждены писать на новом для них Python после поверхностного изучения основ синтаксиса. Этого часто достаточно, чтобы написанный код работал, но сопровождать его становится больно, динамическая природа языка только ухудшает ситуацию. Обычно в таких случаях формируется мнение, что Python не пригоден ни для чего серъёзного.
В общем, моя основная мысль - в bloody enterprise Python может работать вполне хорошо, просто нужно уметь его приготовить.
Интересно. В С разбираюсь не очень хорошо, к сожалению. Но явно какие-то оптимизации есть, судя по вызову для 1500 и 90. Тем не менее - вариант с range получается медленне
def filter_three(x: int) -> bool:
return x in range(100, 1000)
def filter_three_2(x: int) -> bool:
return 100 <= x < 1000
%%timeit
filter_three(500)
> 192 ns ± 14.3 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)
%%timeit
filter_three_2(500)
> 65.4 ns ± 5.15 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
%%timeit
filter_three(1500)
> 164 ns ± 13.1 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
%%timeit
filter_three_2(1500)
> 74.1 ns ± 3.7 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
%%timeit
filter_three(90)
> 153 ns ± 7.18 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
%%timeit
filter_three_2(90)
> 75.6 ns ± 3.55 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
Видимо, я чего-то не понимаю. Почему не будет? Во втором питоне range возвращал список. В третьем - возвращает итерируемый объект. Оператор in в данном случае вынужден перебрать все значения диапазона, пока (не) встретит x. Поправьте, в чем я не прав?
Можно гораздо проще. Так как модули в Python сами по себе являются синглтонами, то достаточно создать инстанс класса и импортировать уже его. За примерами далеко ходить не надо - модуль logging построен примерно по такому принципу, хотя там конечно все устроено немного сложнее, просто это первое, что пришло в голову.
Все когда-нибудь меняется. Конечно, Rust пока Си не убъет, но замена вполне достойная. Давеча ковырялся вот с этой штукой на Blue Pill https://github.com/stm32-rs/stm32f1xx-hal/
Как правильно готовить Python для энтерпрайз - боюсь, что ответ не вместить в комментарий или даже статью. Если очень коротко, то ответ общий для всех ЯП:
голова на плечах
знание ЯП и предметной области
правильное использование нужного инструментария (линтеры, статические анализаторы, и прочее)
хорошее покрытие тестами (для Python, как и для любого другого динамического ЯП нужно очень хорошее покрытие)
опыт
???
Мой опыт говорит о том, что сложную бизнес логику реализовать на Python можно. Так же, при грамотном подходе, можно легко или относительно легко менять её при изменившихся бизнес-требованиях (иногда при кардинально изменившихся).
Python не идеальный язык, у него куча недостатков, производительность - это явно не его (но есть нюансы), динамическая природа привносит много своих неприятностей, однако сфера его применения очень обширная. В корпоративной среде он распространяется очень широко, нравится это или нет.
Опыт мне подсказывает, что для работы с данными используется очень малая часть возможностей Python, как ЯП, потому что в этой сфере важно знание принципов работы с данными и соответствующих бибилиотек. Нюансы и глубокое понимание языка тут не так важно. С исследованиями скорее та же ситуация, если понимать под этим одноразовые Jupyter ноутбуки или скрипты.
В bloody enterprise всё-таки используется немного другой Python (если это не data, ML или AI. Но и тут есть простор для деятельности) со всеми своими достоинствами и недостатками. Бывают, конечно и исключения, особенно когда опытные разработчики вынуждены писать на новом для них Python после поверхностного изучения основ синтаксиса. Этого часто достаточно, чтобы написанный код работал, но сопровождать его становится больно, динамическая природа языка только ухудшает ситуацию. Обычно в таких случаях формируется мнение, что Python не пригоден ни для чего серъёзного.
В общем, моя основная мысль - в bloody enterprise Python может работать вполне хорошо, просто нужно уметь его приготовить.
Соглашусь. Экран без выреза - дорогого стоит. Вкусовщина, конечно же, но мне, например, это было принципиально.
Ура, учёные подтвердили мою теорию!!! /joke
Я не специалист. Почему это подается, как достоинство? Типа радуйтесь - а могли сделать, чтобы требовалось?
Так это прогресс! Раньше говорили про 1% вообще-то
Времени тратится не на столько меньше, чтобы вариант с range был приемлемым
Интересно. В С разбираюсь не очень хорошо, к сожалению. Но явно какие-то оптимизации есть, судя по вызову для 1500 и 90. Тем не менее - вариант с
rangeполучается медленнеВидимо, я чего-то не понимаю. Почему не будет?
Во втором питоне range возвращал список. В третьем - возвращает итерируемый объект. Оператор
inв данном случае вынужден перебрать все значения диапазона, пока (не) встретитx.Поправьте, в чем я не прав?
Можно гораздо проще. Так как модули в Python сами по себе являются синглтонами, то достаточно создать инстанс класса и импортировать уже его. За примерами далеко ходить не надо - модуль logging построен примерно по такому принципу, хотя там конечно все устроено немного сложнее, просто это первое, что пришло в голову.
Ну хотя бы вот так
чтобы не перебирать значения от 100 до 1000 в надежде (не)встретить нужное
Извините, статья, конечно же не про это, но от такого примера у меня глаз задёргался :-)
В РБ ещё работает
Там написано - набор для сборки педали
Простите, я не настоящий сварщик, так, балуюсь иногда в Rust. Возможно по этому я не понял - при чем тут операционка?
Под Blue Pill я имел в виду штуку наподобие этой: https://stm32-base.org/boards/STM32F103C8T6-Blue-Pill.html
Rust embedded работает на голом железе, без OS
Все когда-нибудь меняется. Конечно, Rust пока Си не убъет, но замена вполне достойная.
Давеча ковырялся вот с этой штукой на Blue Pill
https://github.com/stm32-rs/stm32f1xx-hal/
Насчёт установки циферблатов на Mi Band 7 - вместо официальных приложений пользуюсь Gadgetbridge:
https://gadgetbridge.org/gadgets/wearables/xiaomi/#device__xiaomi_mi_band_7
https://f-droid.org/ru/packages/nodomain.freeyourgadget.gadgetbridge/
Ну, а сами циферблаты можно ещё посмотреть вот тут: https://amazfitwatchfaces.com/mi-band-7/top?topof=alltime
Гравитация присутствует всегда, а вот вес будет равен нулю
Так вроде там все живы, здоровы. Нет необходимости срочно из возвращать, поэтому заберут их следующим плановым рейсом.
В качестве контейнера для тестов может служить не только класс, но и модуль. Но ладно, это уже вкусовщина, у каждого свои фломастеры :-)