это просто примеры думаю, к таком не стоит придираться, так как эти функции чисто для примера, то логику их вообще нет смысла показывать, они не несут никакой нагрузки
каким бы хорошим не был проект, какие бы хорошие программисты не сидели за разработкой, всегда есть человеческий фактор ошибки, если с примером values = data_string.split("~") я полностью согласен, что лишнее было делать проверки на isinstance, то в случае, когда в функцию приходят какие-то параметры, особенно если эту функцию вызывает где-то другой человек, то стоит сделать лишнюю проверку, так как не все "гении" и могут допустить ошибку, передав не тот параметр, и тогда, в лучшем случае, тесты не пройдут, в худшем, все тесты пройдут, но в какой-то момент может лечь продукт тут надо думать наперед, что придет какой-то программист N, прочитает документацию, забьет и решит, что в вашей функции уже есть все проверки и будет туда передавать, что попало
в основной работе аннотация типов - это неотъемлемая часть всего процесса в статьях нет таких мест, где бы не было понятно, какой тип данных передаётся, так как либо переменные называются по типу данных, либо описывается в статье, что передается на будущее постараюсь использовать аннотации, чтобы код в статьях был понятнее ____ читать такой синтаксис не трудно, но в сложных условиях мне не доставляет, что объявление переменной идет прямо внутри конструкции if, поэтому для себя я отметил этот оператор не несущим никакой пользы при написании кода конечно, если данный оператор работает быстрее обычного присваивания f = func(i) до if, то я бы посмотрел в сторону :=, чтобы ускорить код, но пока я не проверял эту теорию
да, но словарь в качестве ключа не может использовать нехешируемые типы и более сложные логические конструкции раньше приходилось изобретать велосипед, плодить кучу условий в if/else, использовать словари, создавать в классах отдельные функции для сравнения данных сейчас стало попроще с этим
аннотация типов - полезная штука, которая делает код более понятным и читаемым как по мне, так использование := в условиях/циклах и т.д. нагружает эти конструкции мне проще и понятнее объявить переменную до конструкции, чем использовать :=
TS - имеет типизацию данных и имеет свой компилятор Python - динамический язык с интерпретатором думаю, даже не стоит сравнивать эти языки если уж совсем всё будет плохо, то для Python есть Cyton
к сожалению, аннотация типов в питоне игнорируется интерпретатором конечно, можно использовать какой-нибудь mypy для проверки типов перед запуском, но и это не даст 100% гарантии, что функция будет принимать только тип str
да, такой код будет более оптимизированным, но я стараюсь писать примеры, которые будут понятны всем: и начинающим и более продвинутым, поэтому в примерах может появляться избыточность.
Мне кажется, что там получилась бы довольно интересная матрица. Правда, хуже дела обстоят с менее популярными/молодыми языками, так как для них меньше готовых инструментов существует.
Про Go думал, но в первую подборку языков он не попал. Думаю, поискать еще решений на других языках и сделать вторую часть с другими языками, чтобы у сообщества была информация в прямом доступе о том, какие языки можно вызывать из Python.
Есть различные алгоритмы поиска экстремумов, которые работают в тысячи раз быстрее, чем просто алгоритмы полного поиска, например, генетические, муравьиные, алгоритмы роя частиц, иммунные и другие. В них происходят также случайные отклонения. Например, в алгоритме роя частиц никто ничего не теряет, там просто все частицы получают информацию друг о друге и немного смещают свой вектор поиска экстремума. Я по подобному тоже делал небольшую статейку
Это задача носит чисто познавательный характер: посмотреть и промоделировать поведение выдуманного (это важно!) поселения В реальной жизни используются более сложные и продуманные модели, где данные берутся не просто с помощью random.randint() и учитываются самые важные факторы жизни, а не просто хобби Такие сверхпростые модели можно использовать для моделирования поведения в каких-нибудь простеньких играх
Спасибо! Да, было бы интересно посмотреть, как будет себя вести поселение, если учитывать некоторые демографические показатели В ближайшее время я реализую что-то подобное, где жизнь в поселении уже не будет зависеть от одного параметра
это просто примеры
думаю, к таком не стоит придираться, так как эти функции чисто для примера, то логику их вообще нет смысла показывать, они не несут никакой нагрузки
каким бы хорошим не был проект, какие бы хорошие программисты не сидели за разработкой, всегда есть человеческий фактор ошибки, если с примером
values = data_string.split("~")я полностью согласен, что лишнее было делать проверки на isinstance, то в случае, когда в функцию приходят какие-то параметры, особенно если эту функцию вызывает где-то другой человек, то стоит сделать лишнюю проверку, так как не все "гении" и могут допустить ошибку, передав не тот параметр, и тогда, в лучшем случае, тесты не пройдут, в худшем, все тесты пройдут, но в какой-то момент может лечь продукттут надо думать наперед, что придет какой-то программист N, прочитает документацию, забьет и решит, что в вашей функции уже есть все проверки и будет туда передавать, что попало
в основной работе аннотация типов - это неотъемлемая часть всего процесса
в статьях нет таких мест, где бы не было понятно, какой тип данных передаётся, так как либо переменные называются по типу данных, либо описывается в статье, что передается
на будущее постараюсь использовать аннотации, чтобы код в статьях был понятнее
____
читать такой синтаксис не трудно, но в сложных условиях мне не доставляет, что объявление переменной идет прямо внутри конструкции if, поэтому для себя я отметил этот оператор не несущим никакой пользы при написании кода
конечно, если данный оператор работает быстрее обычного присваивания f = func(i) до if, то я бы посмотрел в сторону :=, чтобы ускорить код, но пока я не проверял эту теорию
да, но словарь в качестве ключа не может использовать нехешируемые типы и более сложные логические конструкции
раньше приходилось изобретать велосипед, плодить кучу условий в if/else, использовать словари, создавать в классах отдельные функции для сравнения данных
сейчас стало попроще с этим
аннотация типов - полезная штука, которая делает код более понятным и читаемым
как по мне, так использование := в условиях/циклах и т.д. нагружает эти конструкции
мне проще и понятнее объявить переменную до конструкции, чем использовать :=
TS - имеет типизацию данных и имеет свой компилятор
Python - динамический язык с интерпретатором
думаю, даже не стоит сравнивать эти языки
если уж совсем всё будет плохо, то для Python есть Cyton
в функцию такую конструкцию передать не получится
но в классах можно настраивать самому шаблон сопоставления
вот кусок кода из PEP622:
match expr:case BinaryOp(left=Number(value=x), op=op, right=Number(value=y)): ...from types import PatternObjectBinaryOp.__match__((),{"left": PatternObject(Number, (), {"value": ...}, -1, False),"op": ...,"right": PatternObject(Number, (), {"value": ...}, -1, False),},-1,False, )лично я не сторонник "моржового" оператора
но да, такая конструкция имеет место быть
к сожалению, аннотация типов в питоне игнорируется интерпретатором
конечно, можно использовать какой-нибудь mypy для проверки типов перед запуском, но и это не даст 100% гарантии, что функция будет принимать только тип str
это не совсем switch/case
pattern matching более усложненная конструкция
Для большей точности в Python лучше использовать не min_distance = 999999999, а min_distance = float('inf')
Спасибо!)
да, такой код будет более оптимизированным, но я стараюсь писать примеры, которые будут понятны всем: и начинающим и более продвинутым, поэтому в примерах может появляться избыточность.
Полезно, спасибо!
Мне кажется, что там получилась бы довольно интересная матрица. Правда, хуже дела обстоят с менее популярными/молодыми языками, так как для них меньше готовых инструментов существует.
Про Go думал, но в первую подборку языков он не попал. Думаю, поискать еще решений на других языках и сделать вторую часть с другими языками, чтобы у сообщества была информация в прямом доступе о том, какие языки можно вызывать из Python.
Спасибо! Про F2Py не знал. Сейчас почитал про него, действительно можно было бы дополнить им.
Есть различные алгоритмы поиска экстремумов, которые работают в тысячи раз быстрее, чем просто алгоритмы полного поиска, например, генетические, муравьиные, алгоритмы роя частиц, иммунные и другие. В них происходят также случайные отклонения. Например, в алгоритме роя частиц никто ничего не теряет, там просто все частицы получают информацию друг о друге и немного смещают свой вектор поиска экстремума.
Я по подобному тоже делал небольшую статейку
Это задача носит чисто познавательный характер: посмотреть и промоделировать поведение выдуманного (это важно!) поселения
В реальной жизни используются более сложные и продуманные модели, где данные берутся не просто с помощью random.randint() и учитываются самые важные факторы жизни, а не просто хобби
Такие сверхпростые модели можно использовать для моделирования поведения в каких-нибудь простеньких играх
Спасибо!
Да, было бы интересно посмотреть, как будет себя вести поселение, если учитывать некоторые демографические показатели
В ближайшее время я реализую что-то подобное, где жизнь в поселении уже не будет зависеть от одного параметра