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

Подскажите как реализовать в питоне и\или pycharm такую штуку чтобы входные данные подставлялись в input ???

пример ( http://pythontutor.ru/visualizer/ )

1- заранее подготовленные входные данные ( то что будет вводиться в input в основном коде)
2- код самой программы
3- вывод результата

Заранее благодарен , с уважением пробник )

Очень просто реализовать. Не пользоваться input.
Для ленивых:

Если нужен именно input можно перенаправить данные из файла в stdin питона.
При этом файл все равно надо создавать, код будет длиннее а файл непонятнее, поскольку не размечен.

Есть еще один действенный секретный способ вместо
написать
и данные магическим способом подставятся автоматически.

я не корректно пример привел , так будет правильнее.

То есть вариант со словарем- “ключ : значение” не подходит , второй вариант (если я правильно понял) под линукс заточен, а третье это вообще не то.
Но все равно огромное спасибо.
Проблема еще актуальна.

probnik
второй вариант (если я правильно понял) под линукс заточен

В винде это будет так
или так

probnik
вариант со словарем- “ключ : значение” не подходит

Кто говорит что там обязательно ключ- значение точно также можно сделать список
a.yaml:

probnik
второй вариант (если я правильно понял) под линукс заточен

Совершенно неправильно понимаете. Под виндой работает идентично. Думаю и pycharm можно легко заточить. Не детализирую как, потому что считаю что если вы не любитель пайпов линукс, то вводить струей неформатированные данные с stdin плохой стиль, граничащий с говнокодом.

probnik
а третье это вообще не то.

:)

probnik
Проблема еще актуальна.

Проблема в том что проблемы вроде как нет. Опишите ясно что вы хотите. Какая у вас последовательность действий. Что не нравится. Как оно должно быть в идеале по вашему мнению.

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

doza_and
то вводить струей неформатированные данные с stdin плохой стиль

Нормальный стиль. Данные должны быть максимально простыми (разделены строками). Если данные имеют формат, то появляются ограничения, которые формат тянет за собой. Например, если надо будет передать строку “- a”, чтобы он её и распечатал, то разборщик формата превратит её в “a”, тогда как нужно распечатать именно “- a”. То есть ты должен сидеть там что-то экранировать. Особенно прикольно получится, когда данные будут не вручную писаться, а приходить из других программ.

py.user.next
То есть ты должен сидеть там что-то экранировать.

Все определяется задачей. Если у ТС есть предопределенные поля - логично использовать конфигоподобный подход. Если как он потом захотел поток данных, то тут я наверное тоже просто поток строк передал.

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

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

doza_and
Если на входе и выходе одинаковая библиотека кодирования- декодирования

doza_and
Данные приходящие из других программ это самое то. Как раз договариваешься с авторами о формате.

Знаешь, как UNIX построена? Там все программы обмениваются текстом (определённое понятие). Поэтому программы, написанные 40 лет назад, прекрасно работают с программами, написанными 10 лет назад. К тому же они все прекрасно открыты для будущих программ, которых ещё нет. И вот это происходит только за счёт того, что данные, которыми обмениваются программы, максимально простые. У формата, если ты не знал, точно так же есть версии, то есть он живёт. Поэтому там не только нужен декодировщик, но и кодировщик должен выдавать данные на примитивном уровне в пределах формата. Иначе может получиться, что кодировщик будет использовать фичи формата, которых нет в декодировщике, из-за того что в декодировщике старая версия формата.

Вот пример: есть sh и bash. В bash'е есть много всяких фишек (массивы там и так далее), но shell-скрипты принято писать для sh, потому что sh есть во всех системах. Иначе может оказаться, что shell-скрипт, использующий массивы, будет запущен на какой-нибудь bsd-системе, где он выпадет, потому что там sh без массивов.

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

Теперь представь, что у него не две программы, а десять. Первые пять он пишет в этом году, а вторые пять ему надо будет писать через десять лет. Что произойдёт с yaml'ом за десять лет? И почему он через десять лет должен будет писать новые программы в старой версии yaml'а? А теперь представь, что у него там не yaml, а простой текст, в котором есть только деление на части (по переводу строки). Такой формат проживёт и 10, и 20, и 30 лет, потому что он очень простой.

py.user.next
Что произойдёт с yaml'ом за десять лет?

А тут и ждать не надо. Парсер yaml уже сейчас по сложности схож с парсером xml. xml за 10 лет никуда не делся. yaml тоже никуда не денется, может только из моды выйдет.

По поводу формата. Он есть всегда. В UNIX на нижнем уровне поток байт. Вы предлагаете уже более сложный формат. Поток байт разделенный переводами строки. Уже надо договариваться что такое перевод строки. Если при обмене данными нужны более сложные понятия, необходимо использовать более сложные форматы. Вы можете их придумать сами, или взять наиболее подходящий общепринятый, что в большинстве случаев более хорошее решение.

Т.е. я хочу сказать, что формат должен соответствовать задаче. Да конечно он должен быть простым, но всеже достататочным для решения поставленной задачи.

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

Но надо ответить на вопросы если значение 5.123 надо его переводить во float? Если ключик может содержать пробелы как это описывать? ну и т.п.

А дальше вам решать. С одной стороны усложнение формата в данном случае добавление одного двоеточия на пару, возможно некоторое снижение скорости обработки данных. С другой стороны существенное упрощение кода для чтения данных, возможность преодолеть сложности с составными ключами, трансформацией типов, комментариями кодировкой файла и т.п. По моему опыту в 99% случаев лучше обойтись существующими распространенными форматами (csv, json, ini, hdf5, python,…) , а не придумывать свои.

p.s.
Кстати ваш формат с разделением переводами строк я бы отнес к простым, но не отнес к часто используемым. Уж больно он бесполезен сам по себе в практических задачах. Иногда числа так пишут. но тогда надо трансформацию в числа делать. Это получается разновидность csv. Ну логи можно так писать. Но в логах всетаки разметка нужна чтобы облегчить фильтрацию нужных сообщений, поэтому логи все больше в базы данных пишут и придумывают дополнительные фичи для разметки. А больше ничего и в голову не приходит.