Для монополизации доступа потоков/процессов к ресурсу можно использовать multiprocessing.Queue
Работать с очередями предельно просто. У вас будет 3 потока-поставщика контента, и 1 поток-потребитель, который и будет писать в базу или еще куда. Не требуется даже заморачиваться с блокировками.
from multiprocessing import Process, Queue
sentinel = -1
def creator(data, q):
"""
Creates data to be consumed and waits for the consumer
to finish processing
"""
print('Creating data and putting it on the queue')
for item in data:
q.put(item)
def my_consumer(q):
"""
Consumes some data and works on it
In this case, all it does is double the input
"""
while True:
data = q.get()
print('data found to be processed: {}'.format(data))
processed = data * 2
print(processed)
if data is sentinel:
break
if __name__ == '__main__':
q = Queue()
data = [5, 10, 13, -1]
process_one = Process(target=creator, args=(data, q))
process_two = Process(target=my_consumer, args=(q,))
process_one.start()
process_two.start()
q.close()
q.join_thread()
process_one.join()
process_two.join()
Не лучше для таких крайне редких случаев в виде исключения использовать рефлексию со статикой?
Я не считаю, что это лучше или хуже в той мере, что нужно жертвовать другими факторами при выборе инструмента. Если бы мне было пофиг на дизайн языка, гибкость, синтаксис, экосистему, и плюс кучу всяких мелочей, я бы просто взял статический.
В моих глазах весь этот спор выглядит как спор про окрас зебры: лучше белая в черную полоску или черная в белую. Также не исключено кстати, что я просто тупой.
Ну вот хоть убейте меня, но я не понимаю зачем в этих случаях обязательно нужна динамическая типизация :)
Может вы и правы. Тут сложно оценивать и сравнивать разный опыт, разные подходы, платформы, случаи. Мы не можем объективно оценить, слишком много факторов разного веса. Я не знаю, насколько локаничны и гибки ваши решения подобных проблем, чтобы говорить, что они плохи. Может они хороши, и ваш язык хорош, а может у вас просто более низкие требования к таким решениям, как например у меня ниже требования к линтерам.
Вообще, сейчас очень активно заняла позицию тенденция движения в сторону гибридных языков. Большинство современных языков стараются обуниверсаливаться: в ООП языки завозят ФП функционал, в динамические языки завозят аннотации и линтеры, в статические — рефлексию и вывод типов. Эту тенденцию видно невооруженным взглядом, потому что на нее есть запрос. И это прекрасно, многие мечтают абстрагироваться от того, что под капотом. Это снизило бы общий порог вхождения, одновременно расширив сферу собственной компетенции как специалиста. Хоть пока это и звучит как утопия, но даже сейчас мы видим какой-то прогресс и тенденцию.
давайте выкинем инструмент, который с гарантией от целого класса ошибок избавляет.
Во-первых, линтеры делают почти то же самое, но без гарантии. Об этом я писал выше. Поэтому не целый класс, а лишь незначительную часть этого класса, на которую линтеры не дают гарантию.
Во-вторых, цена этой гарантии — отказ от возможности выбирать между гибкостью и надежностью. Ну либо для гибкости мы в статическом языке используем рефлексию и получаем те же грабли динамической типизации.
Дык я то с этим и не спорю. Я то как раз против использования магии повсеместно, она усложняет понимание проекта и убивает типизацию. В большинстве задач (по крайней мере в моих) я стараюсь все делать без магии и максимально статично, чтобы все было ожидаемо и предсказуемо.
Магию я использую в двух редких, но необходимых случаях:
1. Если нужен, например, какой-то офигенно прозрачный и гибкий прокси, который сильно снизит сложность клиентского кода, и при этом статически такой модуль сделать не удается (возможно в силу моей квалификации, не знаю). Но как правило, по возможности, такие модули я стараюсь скрывать за статическим адаптером.
2. Если нужно внести срочные, не вписывающиеся в архитектуру правки (например в случае нового типа аварии или атаки). И тут магия очень выручает, чтобы сделать быстро, а уже потом сделать хорошо, расширив архитектуру.
Не даду! Я не могу углубляться в такую бесконечную беседу, не имею столько времени. Все свободное время уходит на отладку ошибок типизации и борьбу с линтером!))
А вы можете привести пример хотя бы одного единственного линтера который это тоже делает? :)
О нет, я спросил про критерии линтера, чтобы убедиться, что мои требования ниже, и что для вас действительно хороших линтеров нет. Среди моих требований только, чтоб с ним не нужно было отдельно возиться, и чтоб оно мне подсвечивало ошибки типов в среде (хотя бы 95%), и чтоб автодополнение работало. Ваши требования я понял, они весьма справедливы.
Ну я собственно к этому и вел, что если проблема в отсутствии супер линтеров, то да, лучше выбрать сразу статический язык.
Ну для меня даже в таком случае остаётся ещё та самая «целая категория». То есть если «забыть» про линтеры, то там всё совсем плохо будет.
В принципе, это тоже справедливое требование. Если есть что-то, что не исключает ошибку на 100%, то за это тоже приходиться беспокоиться. Статические языки исключают эту категорию на 100%, это весомый бонус.
Я что-то пропустил?
Ну я приводил примеры первого уровня, от меня попросили примеров второго уровня (что было предсказуемо).
Суть в том, что если статические разработчики не верят в потребность в некоторых (пускай в редких) местах творить магию, то либо у них нет таких задач, и продолжать спорить бессмысленно, либо они едят кактус (видят только время, сэкономленное на наличии типов, и не видят, сколько времени убито от отсутствия гибкости, хоть и опасной). А может наоборот, я чего-то не вижу. В любом случае, ошибка выжившего мешает объективно оценить картину.
Если вы его приведётё, то у меня в копилке появится самый первый пример.
Разве ваша личная субъективная копилка — это отражение реального мира ИТ?
А если нет, то в неё добавится не знаю уже какой случай когда утверждения есть, а примеры не находятся :)
Подозреваю, что примеров вам дают достаточно, просто вы их не признаете, предлагая сменить решение, следом подход, следом инструмент, следом сферу деятельности. Поэтому у вас в копилке нет примеров. И поэтому мой пример ничего не изменит.
В данном случае доказательство на примерах упирается в эвристику доступности, ошибку выжившего и другие когнитивные искажения.
нормальную интеграцию в любые IDE и CI. И гарантированная обратная совместимость.
Серьезные требования. Полагаю, все статические языки им удовлетворяют?
Конечно можно. Но в них отсуствует целая категория ошибок, которые есть в языках с динамической типизацией.
Согласен полностью с этим утверждением. Только оно не имеет отношения к разговору, потому что мы говорим про динамическую типизацию с аннотациями и линтерами, а значит не целая категория ошибок, а какая-то незначительная часть ошибок из этой категории, с которой линтеры не справились.
примеры преимущества статической типизации вам приводят здесь уже неоднократно
Ну во-первых, примеров я не просил, ибо и без них знаю преимущества статической типизации. А во-вторых, я не очень воспринимаю примеры в духе «статический язык выполняет за программиста его работу».
а вот примуществ динамичeской вы пока особо привести и не можете
Я приводил пример. На что меня попросили привести пример, в каких задачах это нужно. А потом бы меня попросили привести пример, в каких проектах нужны такие задачи и т. д. Собственно, о чем я и говорил, приводя глупый диалог про труп.
Ещё не стоит применять динамику, если у вас с членами команды не гештальт-сознание
В этом случае статику тоже не следует применять. Лучше вообще не заниматься разработкой, потому что типы — это лишь одно из мест, где можно накосячить.
Справедливости ради отмечу, что отсутствие типизации без аннотаций и линтеров — это на мой взгляд жирнейшая причина ошибок.
Если у вас есть такие примеры, то я с удовольствием на них посмотрю.
Я про анализатор всех типов задач, проектов, парадигм и языков во всех комбинациях не просто так упомянул. Если я вам приведу пример, то во-первых это все еще будет не репрезентативная выборка, по которой нельзя судить, а во-вторых дальше будет схватка теорикрафта:
— вам лопата не нужна
— а как я буду копать могилу?
— а зачем вам могила?
— похоронить труп
— используйте кремирование
— у меня нет печи
— постройте
— у меня нет столько кирпича
— постройте маленькую
— тогда труп не влезет
— используйте другой труп, поменьше
И так до бесконечности, пока вы не убедите меня полностью сменить сферу деятельности, задачи и инструменты. Поэтому извините, но нет, в примеры мы скатываться не будем.
Во первых да, достаточно качественных линтеров на мой взгляд всё ещё нет.
В целом согласен. Даже в моем случае линтер не инспектирует 100% случаев и даже встречаются баги. Могу ли я попросить перечислить критерии качественного линтера?
Например надо ещё будет как-то следить чтобы ими пользовались все «участвующие стороны».
Давайте по-чеснаку, в статических языках тоже можно наделать море ошибок, и административные проблемы выбора инструментов, контроля версий, слияния веток, код ревью и т. д. должна решать не типизация и не линтер, а иерархия сеньоров, тимлидов и архитекторов.
В нормальных языках есть вывод типов, который позволяет писать типы гораздо меньше.
Честно говоря, я притомился уже по несколько раз отвечать на одни и те же аргументы. Краткий пересказ для вас:
— Мне пофиг, какая типизация под капотом.
— Потому что вы выполняете работу статического языка в динамическом руками?
— От какой работы программиста меня избавит статический ЯП?
— От расстановки аннотаций и установки линтера
— Я не ставлю линтер, а аннотации используются и в статическом
— В нормальном языке есть вывод типов
Так и в нормальных линтерах, которые уже встроены в IDE, есть вывод типов. И поэтому это не отвечает на вопрос, какую же работу за меня выполняет статический ЯП в этой ситуации. (когда есть аннотации + хороший линтер)
Ну то есть смотрите что получается: типы вам расставлять надо так же как и мне. Если мне вдруг надо «динамическую магию с произвольными неизвестными аргументами», то я могу просто использовать «object» в качестве типа
Ну да, об этом я и твержу уже неделю. Программисту какая разница? Раз типизация становится не такой важной, можно позволить себе выбирать инструмент за другие, на мой взгляд, более важные параметры: гибкость, выразительность, сферы применения.
то я могу просто использовать «object»
Добро пожаловать в мир динамической типизации. Раз в статические языки закладывают такую возможность, значит давайте не будем утверждать, что это никому не нужно? Может и не нужно, но мы то с вами не знаем наверняка, чтобы использовать это как аргумент.
правда я пока не встречал ситуаций где это было настолько необходимо что без этого ну вообще никак
Я уже говорил «я не встречал» — это не аргумент, либо аргумент не для такого уровня беседы. Нужно поднимать тонну типов задач, проектов, команд разработки, парадигм и проводить такой анализ, которого еще не придумали, чтобы делать какие-то утверждения на тему, нужна ли динамическая магия или все задачи решаются статически. И не просто решаются, а решаются как минимум не сложнее, именно это важно.
Но у вас всё ещё остаётся возня с самим линтером. И про «замечателъные варианты из коробки» мне рассказывать не надо, я сам с линтерами работаю и там далеко не всё так замечательно как вы пытаетесь представить.
То есть опять все сводится к одному аргументу — для динамических языков нет качественных линтеров, с которыми не надо было бы возиться, я правильно понял?
Я еще раз повторяю, раз вы не потрудились прочитать, я НЕ подключаю линтер, я просто ставлю среду, как и вы ставите среду для статического ЯП.
и вручную расставив аннотации типов
А в статическом языке типы расставляются как-то не вручную? Там педальный привод в комплекте с IDE поставляется?
Стоит еще отметить, что забытая анотация типа не позволит сломать проверку типов в статическом языке.
Стоит еще отметить, что указывать на особенность, ради которой динамическая типизация и создавалась, в качестве недостатка — это уже неверная риторика. Это типа как сказать, что бензин плохой, потому что легковоспламеняемый, а значит пожароопасный. Ну как бы ради этого оно и создавалось, чтоб применять с умом. А если без ума, или память плохая, то да, лучше конечно с ним не работать.
То есть вы вообще ничего не делаете и у вас магическим образом появляются проверки на соответствие структур?
Ну нет, типы то я должен расставить, где требуется. Иначе описанная мной схема не работает.
А если в каком-то модуле вам требуется творить динамическую магию, пилить всякие супер прозрачные прокси с произвольными неизвестными аргументами, метаклассы, и прочую динамическую хрень, то такой модуль можно внутри не полностью типизировать, а к проекту присоединить через адаптер со статическим интерфейсом.
А линтеры у вас берутся магическим образом из воздуха или вам о них всё-таки самому надо заботится?
Вы плавно меня подводите к выводу, что статический язык выполняет за меня ту работу программиста, которая отвечает за установку и настройку линтера?
Если да, то и это уже давно не так:
1. Линтеры уже встроены в некоторые IDE для динамических языков, и работают из коробки.
2. Статический язык не подразумевает автоматическое наличие линтера. Вы так же должны поставить IDE, в которой уже есть линтер. Кроме того, линтеры для статических языков существуют и как отдельные продукты, которые тоже сами себя не поставят.
Я спрашивал, какую работу _программиста_ за меня выполняет статический язык? Вы же ответили на вопрос, чем статический язык отличается от динамического. Причем ответили, не вникая в контекст, в котором я уже описывал схему с адаптерами и дальнейшим доверии линтеру, где мне не надо выполнять эту вымышленную вами работу. По такому же принципу работает статический язык (внешне, ибо хочу еще раз напомнить, что в этом вопросе мне неинтересно, что там под капотом).
Посему повторяю свой вопрос: для меня, как для программиста, в чем разница, статический язык у меня в руках или динамический?
Работать с очередями предельно просто. У вас будет 3 потока-поставщика контента, и 1 поток-потребитель, который и будет писать в базу или еще куда. Не требуется даже заморачиваться с блокировками.
В моих глазах весь этот спор выглядит как спор про окрас зебры: лучше белая в черную полоску или черная в белую. Также не исключено кстати, что я просто тупой.
Вообще, сейчас очень активно заняла позицию тенденция движения в сторону гибридных языков. Большинство современных языков стараются обуниверсаливаться: в ООП языки завозят ФП функционал, в динамические языки завозят аннотации и линтеры, в статические — рефлексию и вывод типов. Эту тенденцию видно невооруженным взглядом, потому что на нее есть запрос. И это прекрасно, многие мечтают абстрагироваться от того, что под капотом. Это снизило бы общий порог вхождения, одновременно расширив сферу собственной компетенции как специалиста. Хоть пока это и звучит как утопия, но даже сейчас мы видим какой-то прогресс и тенденцию.
Во-вторых, цена этой гарантии — отказ от возможности выбирать между гибкостью и надежностью. Ну либо для гибкости мы в статическом языке используем рефлексию и получаем те же грабли динамической типизации.
Магию я использую в двух редких, но необходимых случаях:
1. Если нужен, например, какой-то офигенно прозрачный и гибкий прокси, который сильно снизит сложность клиентского кода, и при этом статически такой модуль сделать не удается (возможно в силу моей квалификации, не знаю). Но как правило, по возможности, такие модули я стараюсь скрывать за статическим адаптером.
2. Если нужно внести срочные, не вписывающиеся в архитектуру правки (например в случае нового типа аварии или атаки). И тут магия очень выручает, чтобы сделать быстро, а уже потом сделать хорошо, расширив архитектуру.
О нет, я спросил про критерии линтера, чтобы убедиться, что мои требования ниже, и что для вас действительно хороших линтеров нет. Среди моих требований только, чтоб с ним не нужно было отдельно возиться, и чтоб оно мне подсвечивало ошибки типов в среде (хотя бы 95%), и чтоб автодополнение работало. Ваши требования я понял, они весьма справедливы.
Ну я собственно к этому и вел, что если проблема в отсутствии супер линтеров, то да, лучше выбрать сразу статический язык.
В принципе, это тоже справедливое требование. Если есть что-то, что не исключает ошибку на 100%, то за это тоже приходиться беспокоиться. Статические языки исключают эту категорию на 100%, это весомый бонус.
Ну я приводил примеры первого уровня, от меня попросили примеров второго уровня (что было предсказуемо).
Суть в том, что если статические разработчики не верят в потребность в некоторых (пускай в редких) местах творить магию, то либо у них нет таких задач, и продолжать спорить бессмысленно, либо они едят кактус (видят только время, сэкономленное на наличии типов, и не видят, сколько времени убито от отсутствия гибкости, хоть и опасной). А может наоборот, я чего-то не вижу. В любом случае, ошибка выжившего мешает объективно оценить картину.
Подозреваю, что примеров вам дают достаточно, просто вы их не признаете, предлагая сменить решение, следом подход, следом инструмент, следом сферу деятельности. Поэтому у вас в копилке нет примеров. И поэтому мой пример ничего не изменит.
В данном случае доказательство на примерах упирается в эвристику доступности, ошибку выжившего и другие когнитивные искажения.
Серьезные требования. Полагаю, все статические языки им удовлетворяют?
Согласен полностью с этим утверждением. Только оно не имеет отношения к разговору, потому что мы говорим про динамическую типизацию с аннотациями и линтерами, а значит не целая категория ошибок, а какая-то незначительная часть ошибок из этой категории, с которой линтеры не справились.
Ну во-первых, примеров я не просил, ибо и без них знаю преимущества статической типизации. А во-вторых, я не очень воспринимаю примеры в духе «статический язык выполняет за программиста его работу».
Я приводил пример. На что меня попросили привести пример, в каких задачах это нужно. А потом бы меня попросили привести пример, в каких проектах нужны такие задачи и т. д. Собственно, о чем я и говорил, приводя глупый диалог про труп.
Справедливости ради отмечу, что отсутствие типизации без аннотаций и линтеров — это на мой взгляд жирнейшая причина ошибок.
— вам лопата не нужна
— а как я буду копать могилу?
— а зачем вам могила?
— похоронить труп
— используйте кремирование
— у меня нет печи
— постройте
— у меня нет столько кирпича
— постройте маленькую
— тогда труп не влезет
— используйте другой труп, поменьше
И так до бесконечности, пока вы не убедите меня полностью сменить сферу деятельности, задачи и инструменты. Поэтому извините, но нет, в примеры мы скатываться не будем.
В целом согласен. Даже в моем случае линтер не инспектирует 100% случаев и даже встречаются баги. Могу ли я попросить перечислить критерии качественного линтера?
Давайте по-чеснаку, в статических языках тоже можно наделать море ошибок, и административные проблемы выбора инструментов, контроля версий, слияния веток, код ревью и т. д. должна решать не типизация и не линтер, а иерархия сеньоров, тимлидов и архитекторов.
— Мне пофиг, какая типизация под капотом.
— Потому что вы выполняете работу статического языка в динамическом руками?
— От какой работы программиста меня избавит статический ЯП?
— От расстановки аннотаций и установки линтера
— Я не ставлю линтер, а аннотации используются и в статическом
— В нормальном языке есть вывод типов
Так и в нормальных линтерах, которые уже встроены в IDE, есть вывод типов. И поэтому это не отвечает на вопрос, какую же работу за меня выполняет статический ЯП в этой ситуации. (когда есть аннотации + хороший линтер)
Добро пожаловать в мир динамической типизации. Раз в статические языки закладывают такую возможность, значит давайте не будем утверждать, что это никому не нужно? Может и не нужно, но мы то с вами не знаем наверняка, чтобы использовать это как аргумент.
Я уже говорил «я не встречал» — это не аргумент, либо аргумент не для такого уровня беседы. Нужно поднимать тонну типов задач, проектов, команд разработки, парадигм и проводить такой анализ, которого еще не придумали, чтобы делать какие-то утверждения на тему, нужна ли динамическая магия или все задачи решаются статически. И не просто решаются, а решаются как минимум не сложнее, именно это важно.
То есть опять все сводится к одному аргументу — для динамических языков нет качественных линтеров, с которыми не надо было бы возиться, я правильно понял?
А в статическом языке типы расставляются как-то не вручную? Там педальный привод в комплекте с IDE поставляется?
Стоит еще отметить, что указывать на особенность, ради которой динамическая типизация и создавалась, в качестве недостатка — это уже неверная риторика. Это типа как сказать, что бензин плохой, потому что легковоспламеняемый, а значит пожароопасный. Ну как бы ради этого оно и создавалось, чтоб применять с умом. А если без ума, или память плохая, то да, лучше конечно с ним не работать.
А если в каком-то модуле вам требуется творить динамическую магию, пилить всякие супер прозрачные прокси с произвольными неизвестными аргументами, метаклассы, и прочую динамическую хрень, то такой модуль можно внутри не полностью типизировать, а к проекту присоединить через адаптер со статическим интерфейсом.
Если да, то и это уже давно не так:
1. Линтеры уже встроены в некоторые IDE для динамических языков, и работают из коробки.
2. Статический язык не подразумевает автоматическое наличие линтера. Вы так же должны поставить IDE, в которой уже есть линтер. Кроме того, линтеры для статических языков существуют и как отдельные продукты, которые тоже сами себя не поставят.
Я спрашивал, какую работу _программиста_ за меня выполняет статический язык? Вы же ответили на вопрос, чем статический язык отличается от динамического. Причем ответили, не вникая в контекст, в котором я уже описывал схему с адаптерами и дальнейшим доверии линтеру, где мне не надо выполнять эту вымышленную вами работу. По такому же принципу работает статический язык (внешне, ибо хочу еще раз напомнить, что в этом вопросе мне неинтересно, что там под капотом).
Посему повторяю свой вопрос: для меня, как для программиста, в чем разница, статический язык у меня в руках или динамический?