Python serial: как добавить к сообщению CR, LF(\r\n)?

Вроде подробно пишете, а важные вещи всё равно пропускаете:
- какую библиотеку используете под именем serial?
- почему сначала абзац шлёте, а потом шестнадцатеричные цифры?
- почему не апнете всю строку сразу вместо обработки посимвольно с лишним преобразованием в строку и обратно?
- какая спецификация у serial.to_bytes()? Как она интерпретирует списки целых чисел?
- Зачем вы всё послылаете именно так, чем вам не угодили байтовые строки?
Одни вопросы...

bytes_to_send = str_res.upper() + '\r\n'.encode('ascii')
ser.write(bytes_to_send)

Установил python kivy. Почему не работает первая программа?

Ну не дружат они с кириллицей.

Это если не умеешь их готовить. Все внутренние библиотеки, если правильно сними работать, отлично переваривают хоть арабскую вязь в путях (хотя шутки шутками, на счет задомнаперёдового письма не верен=).

Кто может решить задачу на питоне?

Hcuy, Logo, GWBasic, QBasic, QuickBasic, VisualBasic, потом уже в институте был TurboPascal, Assembler, Lisp, Prolog, Delphi ну и пошло-поехало

Кто может решить задачу на питоне?

Hcuy, в смысле на питоне? Тогда его не было еще, питона этого

Кто может решить задачу на питоне?

Hcuy, в смысле? Вы издеваетесь? Вот в чем могут быть трудности решения этой задачи? Только не говорите что в самом решении. Ок, допустим вы не знаете питон. Есть проблема решить вручную?
Три компании: А(300руб/метр, 100 качество), Б(350руб/метр, 120 качество), В(300руб/метр, 110 качество).
Какую выберете?

Кто может решить задачу на питоне?

я специализируюсь на Js React

liaset, пипец. Задача тривиальная, школьная. Это ж как надо "специализироваться", чтобы не решить школьную задачу, которую на бумажке решить можно в 6 классе? Решить для нескольких фирм и обобщить алгоритм, ну ок, 9-10 класс информатика. Не помню уже. Я в 6 такое решал точно.

Сходите к фрилансерам, что ли. они вам за 300р сделают. Может какой-нибудь талантливый школьник себе на этом копейку заработает.

Кто может решить задачу на питоне?

liaset, этот ресурс не предназначен для халявного решения заданий. Вы ошиблись.

Кто может решить задачу на питоне?

На питоне эта задача решается примерно также как на любом другом полном по Тьюрингу языке.
У вас что конкретно вызывает вопросы?

Как будет выглядеть этот код на Python?

edward_freedom, gсудя по предыдущим вопросам автор вполне может и на русском писать очень понятно.
Какой из этого можно сделать вывод?Похоже автор просто спамит сервис и пытается троллить на почве поличтиеских срачей

Как исключить ввод кириллицы, спецсимволов и пробелов?

Евгений, постойте. Ваши стороны какие-то не противоположные.
Отсутствие или наличие каких-бы то ни было требований к паролю не связано с возможностью авторизоваться через соц-сети. Кроме того, если этого условия не будет, то при авторизации через соц-сети это не повлияет на шанс взлома.
Если вы даёте хрому самому создать пароль, то лишние необоснованные и нестандартные условия для его состава лишь осложнят вам использование этой возможности хрома. В данном вопросе автор разрешает только буквы и цифры, а я сталкивался и с более абсурдным ограничением, например максимум 8 символов. Ограничение пароля по длине сверху - это еще один тревожный признак хранения паролей в открытом виде.

Шанс взлома выше, если пользователь не послушал рекомендаций и предупреждений. Если пользователь сделал это не умышленно, а просто из-за слабоумия, то он вполне может с таким же успехом запостить свой валидный пароль в своём статусе вконтакте, чтобы не забыть. Эта, особенно именно эта регулярка не усложняет подбор пароля,а наоборот, упрощает.
Ещё раз. Если пользователь хочет, чтобы его взломали и не слушает рекомендаций, то что ему помешает не слушать также рекомендации держать свой пароль в секрете?

Налицо ошибка атрибуции

Как исключить ввод кириллицы, спецсимволов и пробелов?

DevMan, "домыслы и пространные рассуждения". Именно так. это признак неоднозначно, свидетельствующий в пользу непрофессионального подхода. Может быть при наличии требований к паролю, пароли хранятся и в зашифрованном виде, но практика показывает тут корреляцию.

для этого и нужна регулярка.

Запрошенная регулярка не позволит сделать правильное предупреждение. Она позволит сделать неразумные ограничения или (при несоответствии) выкатить пользователю простыню с рекомендациями по сочинению пароля.
Для правильных предупреждений регулярок должно быть много, а какие-то нежелательные паттерны имеет смысл и вовсе проверять статистически или алгоритмически.

Как исключить ввод кириллицы, спецсимволов и пробелов?

проблема как раз для юзера – когда нужно пользоваться устройством, где внезапно нет национальной раскладки.

DevMan, для этого нужно сделать заметное предупреждение. Если пользователь его увидел, то не надо считать его неразумным идиотом, он может принять решение сам следовать ли вашему предупреждению или нет. А вы решаете проблемы одних пользователей создавая проблемы другим.
Забыть, что кириллицу или символ рубля трудно вводить с других девайсов - это нормально. Об этом можно вежливо напомнить пользователю. Вежливо и эргономично, не в виде пятистраничных рекомендаций по формированию пароля, а в реальном времени и по факту конкретной ситуации: есть кириллица - напомнить о ней, есть символы юникода и смайлы - напомнить о них, есть подозрение на инверсию капса - предположить это и сказать об этом пользователю.

избегать подобного – такое же простое правило как избегать национальных символов и пробелов в путях

Это ваше личное правило. У меня есть знакомая бабушка,которая активно пользуется соц-сетями. Ей вообще никогда не нужна латиница, она не техно-гик и никогда не заходит в свои соц-сети со смартфона или другого компьютера в Турции. У неё всегда по умолчанию кириллица и есть пантосвитчер, чтобы не приходилось перенабирать одним пальцем сообщение при ошибке в раскладке. Она вообще не понимает различий между "О, "O" и "0". А вы со своими пережитками проблем зари компьютеризации в голове сочиняете ей дикие (для нее) требования к паролю.

но вывод, что запрет кириллицы признак хранения пароля в открытом виде, так и остался мной не понятым.

Я повторно апеллирую к вашей логике и внимательности. Повторно обращаю внимание, что выводов не делал, лишь отметил признак свидетельствующий в пользу одной из вероятных причин.
Мой ход рассуждений таков: те дилетанты, которые хранят пароли в открытом виде, с большой долей вероятности собирают SQL-запросы методом конкатенации строк и, весьма вероятно, вообще не умеют правильно их экранировать. Чтобы залётная кавычка, пробел или килобайтный текст в поле не поломали им сервер, они выкатывают тупые требования в том числе и к паролям.
А может быть эти грамотные ребята не умеют нормально работать с кодировками и под виндой, а то и где угодно у них постоянно возникают "загадочные" проблемы с конвертацией не ascii символов для сохранения в файл. Такие дятлы могут неправильно настроить систему логирования и в придачу писать пароль в логи тоже в открытом виде. Даже если они потом посолят и захешируют пароль, в дебаг-логах он вполне может осесть и утечь. Сколько раз такое было? Как по-вашему текут пароли на разных сайтах?

Зачем вообще может кому-то прийти в голову запретить пробелы в пароле? А зачем запрещать минусы и подчеркивания?

Я могу придумать и другие причины: про контроллеры IoT я упоминал, но допустим у них секьюрное приложение с собственной программной экранной клавиатурой, где есть только такие символы. Но как вы оцениваете, что более вероятно? Задавали бы ребята из команды разработчиков такого приложения такой тупой и нубский вопрос по поводу тривиального регекспа? А вот "специалистов" не хеширующих пароли (ага, временно, до релиза, хотя бы) я встречал лично, на серьёзных щах утверждавших мне, что это не проблема. Вот так я делаю предположения. Читайте внимательнее.

Как исключить ввод кириллицы, спецсимволов и пробелов?

Евгений, ух вот вы сейчас подставились, сударь под мою больную тему.

требование к паролю: наличие маленьких букв, больших и цифр, ну и длина минимум 8 символов, вполне логичное требование

НЕТ! Ну в смысле если это делать тупо обязательными условиями.
Смотрите: скажем я везде делаю очень длинные пароли по методу XKCD, за счет длины и вариативности их энтропии хватает, чтобы не баловаться регистром, цифрами и спец-символами. Ваш ресурс заставит пользователя запоминать ещё и какие именно буквы он сделал заглавными, чтобы удовлетворить дебильное обязательное требование. Я не против требования к уровню энтропии пароля. Я против тупых требований, которые мешают жить.

чтобы усложнить получение пароля путем банального перебора

Можно ввести квоту на число попыток ввода неправильного пароля. Эту квоту нужно вводить с умом, например за счет прогрессивного роста таймаута, после которого возможна следующая серия попыток. Легко оценить среднее время подбора пароля брутфорсом с учетом прогрессивных таймаутов и достаточно держать это время на уровне нерентабельности подбора. Разница между действиями пользователя и целесообразно написанного брутфорса не может быть четкой. Если ваши меры борьбы с брутфорсом тупы и однозначны, то злоумышленнику легко под них подстроиться и держаться за один шаг до блокировки.

Парадоксально, но требования к формату пароля зачастую лишь упрощают его брутфорс.

Как исключить ввод кириллицы, спецсимволов и пробелов?

DevMan, о, тогда вы, очевидно ещё больше чем я раздражаетесь от постановки большинства вопросов на этом ресурсе.

а вообще: использование различных раскладок (или одной, но отличной от латиницы) приносит больше неудобств, чем профита.

Согласен. Именно поэтому я написал про предупреждения. Однако загонять в счастье палками - такая себе идея. Благими намерениями выстлана известно какая дорога.
С такими требованиями очень легко переборщить.
Может быть у пользователя есть отточенная хитрая уникальная схема формирования уникальных паролей для разных ресурсов. Если требования к паролю противоречат этой схеме, пользователю будет сложнее придумать и запомнить сложный пароль.

Проблемы проблемами, но это проблемы пользователя, а не ресурса.
Если вдруг это проблемы ресурса, значит что-то там в архитектуре не так: или с экранированием беда, или пароли не хешированы, или хеш-алгоритм кустарный, или у проджект-менеджера устаревшие взгляды на безопасность. В конце концов при нормально построенном процессе пароль несложно и сменить.

Как исключить ввод кириллицы, спецсимволов и пробелов?

Жаль, что на QNA нет дизлайков к ответам. Без них оценка получается однобокой. Несогласные не имеют достаточной возможности выразить своё несогласие, если им лень писать развёрнутую претензию.

Как исключить ввод кириллицы, спецсимволов и пробелов?

DevMan, о, простите. Я перепутал вас с топикстартером. Мельком глянул.
Ок. Для вас я перефразирую вопрос: чем бы, по-вашему, могли быть вероятно обусловлены такие требования к составу пароля.

У нас нет подробной информации, но раз уж мы заговорили о признаках, то поясню. Для меня мокрый асфальт - это признак недавно прошедшего дождя, проехавшей поливальной машины или большой перестрелки нудистов из водяных пистолетов среди города. Существуют другие признаки всех этих явлений: пасмурная погода, характерный запах, раскаты грома, фрагментарность мокрого асфальта, голые люди тут и там...
Домыслы? Пожалуй можно назвать и так. Я домысливаю отчего бы автору пришлось делать такие ограничения, поскольку автор не дал больше подробностей. Окончательные выводы не делаю, но о непрофессионализме сказал лишь как о наиболее вероятной гипотезе. Так уж вышло, что этот признак в моей практике редко означает, что пароль предназначается для ввода на упрощенной клавиатуре кастомного IoT-контроллера. Так же редко, как нудисты на городских улицах.

Итак, что бы вы сочли вероятной причиной таких требований? Просто интересно. Это всего лишь невинные гипотезы и оценочные суждения. Тут нет правых и ошибающихся.

Как исключить ввод кириллицы, спецсимволов и пробелов?

Евгений, отвалидировать бы таких преподов=)
Надо учебные примеры составлять так, чтобы они чему-то учили помимо основной темы лабораторной. Ну или хотя бы не учили плохому.

Как исключить ввод кириллицы, спецсимволов и пробелов?

как вы сделали на основании регулярки, что пароли хранятся в открытом виде?

DevMan, я выводов не делал, я просто сказал, что это признак.
Часто встречаются люди, которые накладывают на ввод пользователя очень странные требования потому что не умеют правильно экранировать строки. В случае пароля это еще и признак хранения пароля не в виде хеша.
Однажды я видел в продакшне даже хранение "зашифрованных", в base64(!), ага, паролей. И нет, там не хеши были в base64? а именно что пароли. На мой непрошенный аудит и WTF горе-разработчики мне заявили, что пароли, же зашифрованные, глазами текст паролей не виден, значит всё хорошо.

А чем у вас обусловлены такие странные требования к паролю? Просто интересно. Видимо я ошибся, да и признаки эти не стопроцентные. Поделитесь в общих чертах куда так ограничивают пароли.

Как это запустить одновременно?

andrew_shipunov, здравый смысл и совесть

Как однозначно переопределить сложение?

Optional в тайпхинтинге не обязателен. По умолчанию всё Optional. Разве что в целях самодокументируемости кода... но с этим справляется дефолтное None.

Конечно лучше делать проще. То, что решил нагородить автор скорее всего излишне.