Мне кажется вы что-то напутали. То про что вы говорите — всего лишь аннотация типов, просто подсказки для программистов и IDE. А вот насчет строгой типизации — python всегда был со строгой типизацией. С динамической строгой типизацией. А если вы подумали что аннотации типов вносят в python статическую типизацию — то это не так.
Да подошло бы, сам хочу винду десятку, чтобы wsl2 заюзать. Но для этого надо ноут новый прикупить, никак не соберусь. Мой старичек с windows 8.1 уже реально слаб для этого, он и виртуалку с линуксом крутит уже в напряге, а еще и докер при этом. А я еще как-то умудрился запустить докер в виртуалке и пока он билдился еще докер в винде, там по скайпу с расшаренным столом пытались разобрать мою проблему. То что это было жутко тормознуто говорить не буду, 2Гб оперативы на виртуалку при полном объеме в 4Гб с двумя запущенными докерами это жесть =)
Ну в python внедрили аннотации типов, но благо их применение не обязательно. Да иногда конечно указание типов полезно, возможно, я даже пробовал начать их применять, но чаще это лишние затраты времени, ничего мне не дающие. Я начинал программировать с C/C++, как-то привык контролировать все типы, что создаю. Да там их проверяет компилятор, но вот не знаю, может это выработалось на подсознательном уровне или может это мое субъективное мнение, но и в python я всегда сам знаю где какой тип у меня и без указания. Единственное где может возникнуть вопрос — это получение данных из импортируемых библиотек, но и там если я не правильно начну обрабатывать возвращаемый тип — сразу вылезет traceback, благо python хоть и динамический, но со строгой типизацией, так что такое сразу вылезет. А иногда наоборот использую возможность динамической типизации в своих целях, после плюсов где надо писать зубодробительные шаблоны, тут все получается быстро и просто. Ну снова видимо повторюсь, каждому свое. Для меня переход со статической типизации на динамическую увеличил продуктивность работы. Вполне согласен, что у других может быть наоборот.
А насчет docker. Сейчас тоже вожусь с одной темой, специально для этого еще изучаю основы nodeJS. Так вот там тоже docker. А точнее vue-storefront. Так с ним вообще не понятное. vue-storefront-api завел нормально, причем как на debian в виртуалке, так и на windows. А вот фронтенд часть vue-storefront клиент для браузера который, так и не могу никак завести, ни на windows, ни на debian. Разработчик, от которого пришла сборка docker-compose со всем необходимым все заводит на ubuntu и вроде все просто, а у меня на debian никак. Неужели между разными линуксами тоже такая проблема совместимости, я вообще думал docker для того и создали, чтобы избавиться от проблем совместимости на различных платформах, не даром у него внутри свой образ линнукса разворачивается, но вот что-то никак.
Я тоже поначалу прогонял свои проекты через разные анализаторы, flake8, pylint, много встречал интересных советов там даже на работающие правильно куски кода, но как писать более правильно. Многие советы из этих линтеров взял на вооружение и стал сразу применять в своем коде. Потом перестал этим заниматься так как занимает много очень времени, а смысла большого для своих мелких проектов нет кроме самообучения и повышения качества кода. Потом на фрилансе когда получил один проект, он вырос в довольно большой объем, около 20000 строк кода примерно сейчас, причем проект еще не завершен, реализовано наверно половина, может чуть больше. И это весь код мой, никакого генерированного от фреймворков, таких как django, так как проект не веб пока, делается как локальная программа с GUI на wxpython. Хотя в будущем есть планы по переводу его на веб часть с django. Так вот просто не хватает времени на линтеры, хотя и хочется снова их использовать. Может еще что новое узнаю. Но пока ограничиваюсь tracebackами если есть ошибки, и побольше гоняю программу в реальной работе, тестируя ее работоспособность в различных вариациях, но бывает конечно когда не все удается предусмотреть и от заказчика прилетает файл ошибок с tracebackом. Специально сделал простенький bat файлик, чтобы на время пока проект не завершен все ошибки скидывались в файл, который и присылают мне на изучение и исправление.
Ну в простых случаях print искомых данных в ключевых местах. В более сложных случаях делаю специальные тесты, чтобы проверить и отладить работу отдельных функций. Но в большинстве случаев стараюсь разбивать код на мелкие функции, чтобы каждая занималась только одной определенной задачей, насколько это возможно. Так и проще отлаживать просто по результатам tracebackа.
Согласен с вами, тем более что у меня есть с чем сравнивать. Изначально я программировал зрячим, а зрение потерял уже во взрослом возрасте, а не с детства. Так что да, какие навыки работы были со зрением, так большинство осталось и без. У зрения есть одно преимущество, когда надо вносить изменения в несколько блоков кода сразу, расположенных в поле одного экрана, то удобно видеть сразу весь экран целиком и вносить правки в другой блок кода, основываясь на другом. А без зрения приходится чаще скакать между ними или чуть больше запоминать, но опять же это не критично.
Согласен. Все такие статьи как под копирку, будто все их пишут из одного и того же источника, только слова немного переставляют. Всегда одни и те же утверждения будто так и только так удобно.
Ну а я не считаю, что удобнее. Я и сам знаю где какие знаки стоят исходя из самого кода, а если где-то синтаксическая ошибка и надо проверить правильность знаков — тогда можно и по символьно проверить, но это бывает все же не часто. Так что как я и писал — у каждого индивидуально, у каждого свое удобно. А в таких статьях всегда почему-то говорят про всех незрячих. Пускай тогда так и пишут, что конкретно вот этому товарищу из Финляндии удобно так, но это ничего еще не значит что так удобно всем. Ну это так, мое имхо.
«Во время работы незрячие программисты не пользуются выравниванием кода. Вообще. Мы расставляем все отступы уже после написания программы, для тех, кто будет работать с ней визуально»
Ерунда полная. Потом вот от таких нескольких людей формируется мнение о всех незрячих. Ерунда полнейшая, у каждого индивидуально. Я вот пишу на python, и всегда использую отступы,, да и на C++ использую, да и на php с html использую, с ними гораздо проще следить за уровнями блоков, чем разбираться в каше к какому блоку принадлежит та или иная строчка. И тот пример с чтением тоже ерунда. мало кто так использует скринридер, чтобы он читал абсолютно каждый символ. чтение таких символов как скобки, фигурные скобки, двоеточие и прочие не нужно. И так понятно где они стоят. А когда нужно проверить именно конкретный символ то только его и смотрят, а читать все время все символы ерунда. Ну и с пробелами тоже ерунда. В итоге несколько публичных незрячих программистов вводят в заблуждение зрячих людей о манере работы всех незрячих программистов.
Ну почему только в C. я и в python предпочитаю так писать, хоть у меня эта привычка и перешла из C/C++ в python, но и тут же данный способ может помочь от опечатки. Конечно скрипт запустится, но в таком случае ошибка выпадет в рантайме, но выпадет, чем уже облегчит поиск проблемы, чем когда произойдет присваивание, никакой ошибки не выпадет, но скрипт будет работать не правильно.
А я делал проще игрушку. К каждой клавише можно привязать любой wav файл. И имея набор нужных звуков — можно с клавиатуры сделать синтезатор чего угодно :) HotSound
Да latency конечно важен, надо будет как-то попробовать запустить ваш tts, чтобы понять его скорость в реалтайме, а не на записи. Но в любом случае включать ваши голоса в rhvoice не очень, там своя структура на C++ и довольно переусложненная, на вашу python архитектуру думаю можно было бы построить удобную управляющую часть.
Качество голоса важно, поэтому, например, голос стандартной microsoft Ирины из виндовс слушается приятнее, чем голоса rhvoice, хотя и он не без огрехов конечно. Ваши голоса понравились. Не знаю зачем их интегрировать в rhvoice, когда у вас готовый свой синтез. Надо делать из них сборку плагина для NVDA программы экранного доступа.
Очень жаль, что из-за вот таких как вам попадались и складывается потом мнение о данных группах людей и отказывают в найме адекватным, а точнее просто пропадают из переписки если приходится об этом упоминать. Многие есть кто работать хочет, но вот найти реальное место не могут. Если получается найти фриланс заказ и то уже что-то, но это редко
Да просто потому что это бесполезная игрушка, также как и сабж из статьи. На пути следования гораздо большую опасность представляют препятствия под ногами, такие как ямы, бордюры, ступеньки и прочее, а не столбы. Этими дальномерами они не определятся, значит для их определения все равно нужно идти с тростью перед собой. А если идти с тростью, то столб определиться также ею, и все эти дальномеры никто не будет использовать. Перед созданием очередного заменителя трости, все эти создатели сначала бы хоть немного изучили и поняли суть ориентации без зрения.
А у меня такой вопрос, может кто-то подскажет. Когда писал на python 3.5, то частенько собирал модули в Extension и компилировал с помощью build_ext. Все работало прекрасно. Потом обновился на последнюю версию python 3.9, начал использовать dataclass. Но столкнулся с тем, что мой способ компиляции перестал работать. Точнее модуль конечно компилируется, но во время работы скрипт падает при вызове инициализации dataclass. Разного рода ошибки с аргументами __init__.
Данную проблему можно как-то решить или это из общих ограничений?
Или надо выбирать либо dataclass, либо обычный класс и компиляция.
А python все пока сам, как-то с командой не складывается.
Ерунда полная. Потом вот от таких нескольких людей формируется мнение о всех незрячих. Ерунда полнейшая, у каждого индивидуально. Я вот пишу на python, и всегда использую отступы,, да и на C++ использую, да и на php с html использую, с ними гораздо проще следить за уровнями блоков, чем разбираться в каше к какому блоку принадлежит та или иная строчка. И тот пример с чтением тоже ерунда. мало кто так использует скринридер, чтобы он читал абсолютно каждый символ. чтение таких символов как скобки, фигурные скобки, двоеточие и прочие не нужно. И так понятно где они стоят. А когда нужно проверить именно конкретный символ то только его и смотрят, а читать все время все символы ерунда. Ну и с пробелами тоже ерунда. В итоге несколько публичных незрячих программистов вводят в заблуждение зрячих людей о манере работы всех незрячих программистов.
HotSound
Данную проблему можно как-то решить или это из общих ограничений?
Или надо выбирать либо dataclass, либо обычный класс и компиляция.