py.user.next
В общем случае, если есть возможность сделать приложение

Не совсем ясно что вы имеете ввиду. Написали питон скрипт. Это приложение или нет? написали динамическую библиотеку или шарповую сборку это приложение?
1 нужно тогда договориться что такое приложение.
2. на основании свойств декларируемых в определении показать кому (пользователю, программисту, продавцу ПО, производителю оборудования правительству?) и чем оно лучше (быстрее работает, удобнее, проще в разработке )
3. Очень интересно было прочитать про портирование библиотек на андроид. только их еще к андроидовскому питону надо прикрутить. И это вы предлагаете человеку который через ком данные не может получить? Вообще я далек от этой темы, может оно конечно и заработает волшебный образом. Интересно посмотреть как вы сделаете на питоне hello! с использованием порта wxWidgets например.
4 Браузер это универсальное GUI решение для отображения данных пользователю. Он вполне в состоянии выводить данные с темпом в котором пользователь их может воспринимать. Почему это он не подходит? Конечно было-бы гораздо лучше будь в андроиде нормальная консоль. Тогда я бы советовал выводить данные в нее.

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

doza_and
Не совсем ясно что вы имеете ввиду. Написали питон скрипт. Это приложение или нет?

wiki. приложение

doza_and
написали динамическую библиотеку или шарповую сборку это приложение?

Приложение - это то, что будет потом её использовать.

Прикладное ПО ставится в противоположность системному ПО.

doza_and
1 нужно тогда договориться что такое приложение.

Это классическое определение.

Вот ты предложил использовать готовое приложение - браузер. Но мы-то имеем дело с мотоциклом, который постоянно работает и где важно отличать то, что происходит сейчас, от того, что было 0.1 секунды назад.
Даже если будешь передавать json какой-нибудь, это всё равно медленно, потому что передаёшь текст. А тут нужно передавать поток байт (флажки и числа).

doza_and
2. на основании свойств декларируемых в определении показать кому (пользователю, программисту, продавцу ПО, производителю оборудования правительству?) и чем оно лучше (быстрее работает, удобнее, проще в разработке )

Я имею в виду, что, подстраиваясь под программу, можно принять костыльный вариант, который даже будет функционировать поначалу. Но при первой же доработке всё развалится, потому что костыльный вариант где-нибудь вылезет боком (наложит свои ограничения). И когда надо будет делать дела, ты будешь сидеть и думать, как в этой обрезанной версии, которая работает, достичь новых возможностей, которые понадобились.

doza_and
Интересно посмотреть как вы сделаете на питоне hello! с использованием порта wxWidgets например.

Я имел в виду, что для вывода в консоль в Java нужно делать кучу ненужных действий(а в них - ещё кучу ненужных действий) в отличие от питона. Да, и в питоне можно выбрать то, что удобнее, тогда как в Java ты уже выбрал, а дальше, если что-то не выходит, - твои проблемы. Медленная платформа? Терпи. Неповоротливые пакеты? Терпи. Лень писать имена по 30 символов? Терпи. Не хватает функционала? В следующей подверсии новой версии будет. И всё в таком духе.

doza_and
И это вы предлагаете человеку который через ком данные не может получить?

Человек не может освоить Kivy, хотя она простая, это о чём говорит? Что человек не напишет сам - значит, писать будет кто-то другой. А если писать будет кто-то другой, то на чём он будет писать? На чём-то распросранённом, хорошо известном, с известными возможностями и особенностями. А что распространено? То, что перечислено выше.

А Kivy - сегодня оно есть, завтра - нет; сегодня оно работает, завтра - баг какой-нибудь появится и будет висеть годами.

doza_and
4 Браузер это универсальное GUI решение для отображения данных пользователю.

Текстовых данных или медиа. А тут надо сигналы посылать от устройства, какой же это браузер? Нужно окно с опросом устройства.

doza_and
Он вполне в состоянии выводить данные с темпом в котором пользователь их может воспринимать.

Да мотоцикл взорвётся, а браузер об этом узнает только через какое-то время. Типа как Солнце если погаснет, нам на Земле оно ещё будет 10 минут светить.

doza_and
Конечно было-бы гораздо лучше будь в андроиде нормальная консоль.

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

Тут спора не получиться. Я согласен с большинством тезисов которые вы выдвигаете.
Был момент когда мы наткнувшись на проблемы разработки приложений на c++ FORTRAN выбирали инструменты для работы с gui скриптами и базами данных. Смотрели и пробовали Java в том числе. Но выбрали для решения этих задач Питон :).

По поводу определения. По нему броузер приложение.

По поводу темпа отображения. Поскольку я занимаюсь компьютерными тренажерами, то могу определенно сказать какие требования к пультам панелям и индикаторам на атомных станциях самолетах и танках (про мотоциклы не знаю к сожалению). Темп обновления цифровых индикаторов 3 раза в секунду. Индикаторы типа лампочек и зажигающихся табло 10 раз в секунду. Более быстрые изменения не воспринимаются оператором. Это все с большим запасом. Реально достаточно обновления раз в секунду. Латентность обычно требуют пол секунды. Броузер такой темп легко держит.
Если вы посмотрите современные СКАДА (https://ru.wikipedia.org/wiki/SCADA) системы то все они предлагают кроме классических еще и отображающие системы на основе веб интерфейса.
Похоже от десктопных приложений реализующих GUI большая часть народа уже перешла на броузеры, которые предоставляют стандартизированный подход к созданию интерфейса с пользователем. Подчеркну еще раз что проблем там тоже хватает.

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

doza_and
Но выбрали для решения этих задач Питон :).

У меня сетевой сканер, он на PyQt, но медленный. Причём медленно жмутся сами кнопки, когда привязаны к слотам. В примерчиках-то они быстро работают, а когда уже связываешь их в программе, всё становится каким-то неповоротливым.
Но благо его можно быстро переписать на C++, поэтому я как бы его не бросаю, а продолжаю развивать.
Питон хорош тем, что можно быстро что-то как добавить, так и убрать. В C++ эти действия - медленные процессы, так как не только букв писать больше надо, но и требуется постоянная компиляция с запуском и анализом результатов.

doza_and
Темп обновления цифровых индикаторов 3 раза в секунду. Индикаторы типа лампочек и зажигающихся табло 10 раз в секунду. Более быстрые изменения не воспринимаются оператором.

Вот про то и речь, что если сделать 0.3 секунды, этого может не хватить ему в каком-нибудь случае и надо будет делать 0.1 секунды (либо довольствоваться тем, что есть). А когда всё уже будет написано для 0.3, переделывание может потребовать создания нового GUI.

doza_and
Броузер такой темп легко держит.

Ещё надо будет тестировать на разных браузерах, чтобы где-нибудь не оказалось всё совсем не так, как ожидается. ;)

py.user.next
Ещё надо будет тестировать на разных браузерах,

На том броузере и устройстве на котором автор собирается отображать данные. Он ведь не промышленное решение делает а для себя. Кстати пром решения тоже не тестируют на всех броузерах а в спецификации указывают требования что должно использоваться. Работа с IE это такая головная боль что просто этим никто не занимается. Видел проекты заточенyые под IE + IIS + C#. Оно несовместимо с другими броузерами. Но по сути IE это исключение. В остальном разницы практически нет.
Отличить 0.1 сек от 0.3 можно только если постоянно пялиться в монитор. А водителю надо еще на дорогу смотреть. Тут думаю и одной секунды с головой. Но то как ТС захочет.

doza_and
На том броузере и устройстве на котором автор собирается отображать данные.

А вдруг там сервис какой-нибудь и у мастеров разные устройства.

doza_and
тоже не тестируют на всех броузерах а в спецификации указывают требования что должно использоваться

Типа как в анекдоте:
- Доктор, я когда рукой вот так поворачиваю, у меня болит.
- А вы так рукой не поворачивайте, и не будет болеть.

Не зря же он Kivy выбрал - значит, ему кроссплатформа нужна.

py.user.next
А вы так рукой не поворачивайте, и не будет болеть.

Хорошо замечено. Так чаще всего и делают.:)