deepblack

пишу GUI на android, хотелось бы снизить количество потребляемой оперативной памяти.

Не пишите на Python.

Есть Telegram bot API - это для ботов. А есть Telegram client API - это для приложений, вполняющих функции клиентской стороны. То есть если вы задумаете написать свой клиент для телеграмма, то будете пользоваться этим API. Некоторые злоупотребляют правилами и делают ботов с использованием этого API, чтобы боты ритворялись реальными аккаунтами. За это, по идее, должны банить.
Не надо делать таких ботов. Для чего вам?

docker log rotation

Импортировать нужные классы/функции и запустить их в отдельном потоке.

Ну, есть универсальный патч. Он особо подходит для тех, кто считает, что из всех дистрибов ему нужен почему-то Kali - ужасно узко специализированный дистриб для ИТ-безопасников, на нубов не рассчитанный от слова совсем.

a1=$(cat file1.txt |egrep -o '^a=[^\r\n]+$' |head -n1 |cut -d"=" -f2)
b1=$(cat file1.txt |egrep -o '^b=[^\r\n]+$' |head -n1 |cut -d"=" -f2)
if [ -n "${a1}" -a -n "${b1}" ]; then
    echo "${a1}-${b1}" >>out.txt
fi

А вот перебор по всем файлам в директории мне делать лень, поэтому пусть это будет вашим домашним заданием, сделайте ну хоть что-нибудь своими руками!

elif - это сокращение от else if, что в переводе значит "иначе если". Иначе если что в вашем случае? Условие-то где в условном выражении?

В принципе, сама по себе Android Studio - не сильно требовательная. В основном, вся боль начинается при сборке и запуске проекта на эмуляторе.
Начинал тоже, с древнего ПК, (там по моему даже 4 ГБ ОЗУ не было).

Решил проблему - запуском на реальном устройстве, девайсе, вместо эмулятора.

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

В таких ситуациях правильнее будет сказать "Каковы условия оплаты данного задания?". Большинство неадекватов на этом этапе отсеиваются. Просто потому что не только вы что-то делаете для работодателя, но и он вам что-то дает. Если работодатель хочет получить какую-то работу еще до начала трудовых отношений - то следует задуматься, а нужен ли вам такой работодатель? Я просто из исследовательского интереса прошел несколько десятков тестовых заданий и я НИ РАЗУ не получил какого-либо фидбэка. По ощущениям - на результаты тестового никто не смотрит и всем тупо пофиг на него. Поэтому когда мне предлагают тестовое задание - всегда сразу спрашиваю оплату. Никто не хочет платить - это факт, тут ничего не сделать. Почти всегда сразу в отказ идут. Было несколько случаев, когда вроде согласились - но все равно ушли в закат. В целом же, в практике был лишь один случай, когда ко мне пришли и сказали - вот ты умеешь то-то и то, вот тебе тестовое задание, оцени, мы тебе денег сразу заплатим, а там если все пучком - будем работать дальше. И еще несколько случаев, когда работодатели сразу в описании вакансии писали, что тестовое задание оплачивается. Смотреть код тоже почти никому не интересно - такой случай тоже был лишь один, когда я предложил показать код, согласились посмотреть и поспрашивать про него. В абсолютном большинстве остальных случаев, адекватные работодатели сразу говорят: по результатам собеседования нас все устраивает, далее делаем так - вот тут у нас список задач, выбирай одну-две-три простых задачки, если все отлично - работаем дальше, если нет - ну что ж, выдадим зарплату за эти задачки и разбежимся миром. Все остальные, где там сложные и долгие интервью то с одним, то с другим, то задание такое, то сякое - больше на лотерею похоже, когда крутишь барабан и гадаешь - будет сектор приз или сектор ноль.

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

Специально - нет, не нужно. Разве что по результатам прохождения курса учебного какого - можно выложить. Ну и пет-проекты никто не отменял - вот их да, можно и нужно выкладывать на гитхаб и периодически подкармливать.

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

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

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

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

e2e - енд ту енд, тестирование от начала до конца какой-то функциональности. Оно не совсем в эту иерархию вписывается. Скорее как тест, который имитирует работу пользователя. Например юнит тест можно сделать внутренними инструментами, интеграционный тоже. А e2e должен ну как минимум имитировать реального пользователя или реальное окружение как продукт будет использоваться.

Потому что GitHub его выпилил уже полгода как.

Permanently disabled the unencrypted Git protocol

Гуй виснет, потому что вычисления выполняются в том же потоке.
Решение тут одно - вынести логику в отдельный поток и организовать связь между ними.
Но лучше используйте не tk а pyqt. У него больше инструментов, в том числе и для выполнения работы в фоне.