Александр

Я очень долго гуглил этот вопрос. И ничего не помогало.
Суть в том, что напрямую RTF в текст на Linux в python'е перевести нельзя.
Точнее можно, если он содержит только английский текст.
А вот с русским большие проблемы. Но есть лайф-хак.
Как я уже сказал, если попробовать

import textract
import pypandoc

pathname = '<path to file>'
text1 = textract.process(pathname).decode('utf-8')
text2 = pypandoc.convert_file(pathname, 'plain')

то text 1 будет содержать некоторую служебную информацию из файла,
а text2 -- различные вариации кривых символов вместо нужных.

С pandoc всё глухо -- он вещь в себе.
А вот textract работает через unrtf, который в последних версиях (я пробовал на 0.21.10) умеет в кириллицу. Но с оговорками: если попробовать конвертировать сразу в текст, вы получите пустоту. Нужно сначала конвертировать в html:

import pypandoc
import textract
import os

pathname = '<path to file>'
os.system(f'unrtf --html {pathname} > {pathname}.html')
pathname += '.html'
text1 = text = textract.process(pathname).decode('utf-8')
text2 = pypandoc.convert_file(pathname, 'plain')

Вот теперь всё правильно. Одно плохо: нельзя всё сделать, оставаясь только в python'е.
Приходится вызывать shell. Но зато в текущей рабочей директории будут появляться вложенные картинки в формате имён pict[NNN].[ext]. Дело в том, что unrtf выводит текст или html в стандартный вывод, а файлы, соответственно в текущую директорию.
Параметра с выводом файла у него нет.

Главной загадкой в этом вопросе для меня остаётся, почему
unrtf --html file.rtf > file.html
получает текст, а
unrtf --text file.rtf > file.txt
нет.

Но решение всё равно остаётся кросс-платформенным и компактным (чего не скажешь о варианте с lowriter из Libre Office), так как в pip есть и textract и unrtf (для установки которого на windows вам потребуется 2015 студия на win7, либо свежая на win10...).

Для подобного тестового кода можно использовать ab (Apache HTTP server benchmarking tool)

Например так
ab -n 10000 -c 1000 http://localhost:8080/

Где:
-n это количество запросов, которое нужно сделать
-с это количество одновременных запросов

Запустил у себя на одном из серверов, результат вот такой

Server Software:
Server Hostname:        localhost
Server Port:            8080

Document Path:          /
Document Length:        5 bytes

Concurrency Level:      1000
Time taken for tests:   0.509 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1210000 bytes
HTML transferred:       50000 bytes
Requests per second:    19627.39 [#/sec] (mean)
Time per request:       50.949 [ms] (mean)
Time per request:       0.051 [ms] (mean, across all concurrent requests)
Transfer rate:          2319.25 [Kbytes/sec] received

Т.е. при 1000 одновременных запросов сервер сможет обрабатывать в среднем 19627 запросов в секунду

Но важно понимать, что в реальном проекте у вас будет не один endpoint, и что каждый endpoint, в зависимости от того, что он будет делать - будет показывать разный RPS.

Например если сейчас вы добавите еще один endpoint и будете делать запросы в базу для формирования ответа - RPS будет значительно меньше.

Это уже проблема заказчика. Мои заказчики обычно очень тупые, поэтому я кидаю им какой-нибудь архив с кашей, а по факту программу запускаю в своём собственном облаке. Но если заказчик пытается имитировать признаки интеллекта, то почти всегда достаточно скинуть ему контейнер докера со словами: "Просто запустите это контейнер с нужными аргументами." Этого достаточно, чтобы заказчик 2 недели пытался импортировать в свой докер мой образ из zip-архива, а потом сдался либо нанял наконец сис. админа вместо студента 2 курса. Особенно радуют заказчики, которые находят гайд на докер под линукс, поднимают на своём любимом Windows Server виртуалку VMWare Workstation с линуксом, внутри неё докер, внутри докера мой контейнер.

Нагуглил Yappi.

random.choices([5,7], weights=[80,20], k=1)[0]

Либо нечто похожее через cum_weights

random.choices([5,7], cum_weights=[0.8, 1.0], k=1)[0]

https://docs.python.org/3/library/random.html#rand...

это же старый добрый vi
https://ru.m.wikibooks.org/wiki/Vim

Тебе уже отвечали, как назначить тот же Nano редактором, т.к. у тебя Vim открывается (тож не люблю его за чрезмерную занудность), но можно и так в Терминале (Ctrl+Alt+T) выбирать редактор в любое время:

select-editor

Выбираешь редактор соответствующей цифрей из подсказки (здесь 1 - редактор Nano) и жмёшь на Enter.



Отркоется файл crontab в редакторе Nano:


Вписываешь задание -> Ctrl+O (команда на сохранение) -> Enter -> Ctrl+X (выход из Nano)

Ежели он - редактор Nano не установлен (при выборе его выкинет, что он не установлен), то установи его Pacmanом и повтори заново команду:
select-editor

Это vi / vim
После запуска вы в командном режиме. Нажмите i (insert) и вы в режиме вставки, как в обычном текстовом редакторе. Поработали, поредачили, нажмите Esc(можно пару раз, для надёжности ;-)) Всё, пришло время сохраняться и выходить. Есть два варианта. Использовать хоткеи или команды. Хоткеями -- Зажимаем Shift и не отпуская жмём ZZ, да, джва раза, это если хотите сохранить результаты работы -- выход с сохранением. Если передумали сохранять результаты работы(ну мало-ли, случайно зашли, испугались и обругали Линуса и всю юниксовую братию, прямо поверх fstab) так-же, зажимаете Shift и жмёте ZQ. Второй вариант нажать : и внезапно оно появится внизу экрана, в командной строке, туда можно ввести wq (write quit) и выйти с сохранением, нажав ентер или ввести q! (quit!) и выйти без сохранения. Если передумали и решили ещё попечатать, нажмите Esc и вот вы снова в исходной точке, можно жать i или v (visual) -- визуальный режим где можно, от текущей позиции курсора выделить кусок текста и загнать его в буфер пуковкой y (yank), а потом подогнать курсор к нужному месту и не входя в режим вставки нажать p (paste). Вот совсем вкратце как-то так.

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Для удобства длинный строковый литерал в программе можно разбить на кусочки:

s = ("Очень длинная, очень очень длинная, очень очень очень длинная "
     "сттррроооокккккаааааа!")

Никакой конкатенации рантайм не происходит - всё при компиляции.

ps Stanislav Pugachev, проще, наверное, тут от прямого.

проще наверное от обратного тут

s = 1 + 2
s = (1 + 2)
s = (
   1 + 2
)
s = (
   1
   +
   2
)

все эти операции по сути одно и тоже
скобки часто объюзят как в последнем примере потому что так удобно записывать операции растянутые на несколько строк

то есть применительно конкретно к вашему вопросу мы имеем все тоже самое но в обратную сторону

s = (
    "Привет"
    "Мир"
) 
s = ("Привет" "Мир")
s = "Привет" "Мир" // что есть обычной конкатенацией в питоне

если непонятно почему опускаются скобки - то это просто потому что они ничего по сути не группируют
в моем примере будет

s = (1 + 2)
s = (3)  // какой смыл тут от скобок?

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

У VK CallBack Endpoint'a нельзя указать порт, то есть все запросы будут идти на 80-й в любом случае. Дальше на своем сервере можете проксировать куда угодно.