Сергей П

Для более точного ответа нужно болше кода и полный стектрейс.
Но уже здесь видно, что вы неправильно кодируете строку. Зачем-то еще и приводите байтовый литерал к строке... Мне кажется у вас там не china в случае ошибки.

Если вы хотите сохранить в БД бинарные данные. то у вас есть три варианта:
1) Хранить в БД данные в поле типа binary blob. В таком поле может храниться произвольный набор байтов, он не птается преобраховаться в строку при работе.
2) Хранить в БД экранированную строку в поле обычного строкового типа. При этом все непечатные и спец-символы должны быть экранированны специальной последовательностью, которая состоит из печатных обычных символов. Тогда нужно перед испольованием полученных из БД данных разэкранировать строку и получить байты.
3) Можно хранить данные в БД в обычном текстовом или текстовом blob-поле, но в виде закодированно последовательности base16 или base64. В base64 каждые два байта кодируются тремя символами из 64-битного набора печатных символов. Нужно кодировать и декодировать такие строки при сохранении\загрузке.

Вам больше всего подходит base64. Посмотрите в документации как с этим работать

Самым правильным будет не округлять, я преобразовывать в строку с нужной точностью.
f'{54 / 11:.1f}'
Обычно в вычислениях нужно работать с по возможности наиболее точными числами. но выводить в результате округленные числа без лишних знаков.
Округление с помощью round для этих целей может сделать "сюрприз". Не все дроби можно представить конечным числом знаков в любой системе счисления. Например, в десятичной системе нельзя представить 1/3, а в троичиной легко, как и в девятиричной. В двоичной системе не получится представить 0.2, а в десятичной вот я только что это сделал. В двоичной системе счисления получится периодическая запись.
В компе числа с плавающей токой представлены в двоичной форме, и да, некоторые десятичные числа с конечным числом знаков после запятой будут в двоичном виде запиываться не точно. потому что потребуется бесконечное число знаков для точной записи.
В общем, round испольуем только если по алгоритму нам требуется округленное значение в промежуточных вычислениях. Для округления результата с целью показать человеку нужно использовать округление при приведении к строке.

b - это не кортеж. Это просто единичка (int)
Вот так правильно:

a = ()
b = (1,)

Воспринимайте tail и head не в глобальном контексте, а локально. Это всего лишьпеременные с таким именем. Вкаждом конкретном случае и на каждой итерации они могут означать разные места связного списка.

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

Что конкрено не понятно?

Вот поэкспериментируйте сами:

class ListNode:
    def __init__(self, val, next=None):
        self.val = val
        self.next = next

    def __str__(self):
        tail = self.next and f', {self.next}' or ''
        return f'{self.val!r}{tail}'

    def __next__(self):
        if self.next:
            return self.next
        raise StopIteration

    def __iter__(self):
        item = self
        while item:
            yield item.val
            item = item.next

    def copy(self):
        return ListNode(self.val, self.next and self.next.copy())
    
    __repr__ = __str__


 ln=ListNode; l=ln(1, ln(1, ln(2, ln(3, ln(3)))))

Вот так:

print(*[k for k,v in vars().items() if v == ['Яблоко', 'Груша', 'Арбуз']])

Но думается мне вы не этого хотели.
Просто начните с книжки, а не методом проб и ошибок. Сэкономите массу времени.

Вы выбрали плохой путь по ряду причин.
Во-первых, вы пытаетесь вычитать весь 20гб файл в оперативную память. Это будет долго, отожрёт кучу свопа и не факт. что завршится успешно.
Во-вторых, вы пытаетесь запустить весь SQL за один раз - это вы правильно поняли.ч то проблематично.
Ну а в-третьих...
В общем, следует глазами посмотреть в SQL и понять что там. Если там дамп БД, то сперва идут стейтменты для содания таблиц, индексов, хранимок, а потом уже операции вставки в эти таблицы.
Ваш файл называется "часть 3", так что, возможно, часть нужных стейтментов для создания структур просто оказались в других фвйлах.
Обычно кусок SQL, который создаст все таблицы, не так уж и велик по размеру. Можно открыть файлы с дампом текстовым редактором и вытащить оттуда куски SQL из начала с созданием структуры. Положить эти кусуи в отдельный файл. Иногда в SQL-файле с дампом лежит и команда создания базы, посмотрите внимательно.

Когда у вас операции вставки данных в БД в отдельном огромном файле, всё тсановится чуточку проще.
Если у вас задача одноразовая и нужно просто найти один номер и больше ничего, то можно просто воспользоваться командой grep на SQL файле. Она поищет нужный номер и покажет строчки, в которой он встретился. Параметры командной строки могут настроить выхлоп так, чтобы показывались несколько строчек. Это, возможно пригодится, если отдельные стейтменты со вставками занимают по много строк. Так можно быстро найти нужные данные не возясь с поднятием БД.

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

Или вызывайте вот так:
print(subprocess.getoutput('./1.py'))
Так вы дождётесь полного выхлопа.
Но если выхлопа много, то лучше запускать иначе, чтобы получить выходной пайп и вычитывая его в цикле слать всё на stdout __main__

UPD: Дополню ответ, а то часть оказалась в комментариях.

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

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

Потому что вы два раза пытаетесь зачем-то спарсить http-ответ как JSON. Очевидно в Json один ответ.
Вы ришли в магазин, запросили коробку конфет, вскрыли, получили список конфет и выкинули вместе с коробкой и конфетами.
Потом снова делаете двидение руками, будто берете с прилавка коробку конфет (но ее там нет же, вы только одну запросили у продавца), лезете в воображаемую коробку рукой и не находите там конфету.
Странно, правда?

Если бы вы не нарушалиправило и не постили код в виде скриншотов, то я бы вам процитировал ваши ошибки и, наверно даже, написал бы как равильно делать.
Но вы нарушаете правила.

А в чем, собственно, у вас с этим проблема? Что особенного в этой графике? Пиксели крупные, ну так и вы нарисуйте пиксели крупные. Можно даже графический режим такой включить, но смысла мало, можно просто рисовать пиксели прямоугольниками.
Я понимаю речь бы шла о текстовом режиме, но тут-то что такого MS-DOS'овского?
PyGame и в путь.

Почему csv iterator не записывает все, хотя должен?

Нет, не должен. Итератор не должен ничего записывать, он интератор. Итератор итерирует. Всё.

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

Во-первых, вы не привели примера данных. Если что-то идёт не так, как ожидается, ВСЕГДА нужно приводить два набора данных: тот, который работает как ожидается и тот, который как ожидается не работает. При этом не обязательно приводить полные наборы данных, ведь их может оказаться очень много. Всегда нужно стараться упростить непонятную ситуацию максимально, и в какой-то момен она станет понятной. Ну, то есть, возможных причин проблемы в рассмотрении станет достаточно мало, чтобы понять какая из них действительна.
В данном случае нужно было убирать из CSV всё лишнее до тех пор, пока проблема сохраняется. Если убирать уже нечего, то останутся только проблемные записи и, возможно, посмотрев на них, вы сразу всё поймёте. Или поймёт тот, к кому вы пришли с вопросом.

query = """variables_loaded[variables_iterator]['0']""" ##, так далее

Во-вторых, у вас какой-то совершенно невалидный SQL-запрос. Он бессмысленный и неправильный. Вот это буквально текст, который запросом не является. Он даже не меняется от итерации к итерации, понимаете? Нам тут не ясно что вы имели в виду под "так далее", нам тут не ясно понимаете вы что такое SQL и что вот та строка им не является.

При всех ваших ошибках в постановке вопроса нам тут уже не ясно, может быть у вас вообще нет работающего кода, который что-то записывет из CSV в БД, а то, что вы думаете он, якобы, запсывает, уже и так есть в БД, а вы просто этого не понимаете! Ну как не понимаете, что проблема может быть в SQL-запросе, поэтому его не приводите, как не понимаете, что проблема может быть в индексах и структуре БД, поэтому не приводите её структуры, как не понимаете, что проблема может быть в данных (они могут повторяься в разных строках CSV), а вы и не приводите все данные, и не говорите, что убедились, что они не повторяются!

execute_query(connection, query)

В-третьих, вы оставляете за скобками код выполнения SQL-запроса. Мы не знаем что это за код, может быть там вы тупо try-except'ом задавили все возможные ошибки и сами, фактически, отказались от того, чтобы БД вам объяснила в чем проблема. Может быть это вообе пустая функция внутри, или она неправильно обернута каким-нибудь декоратором, который ей не дает работать, а вы просто видите в БД одни и те же данные, и думаете. что они каждый раз туда заливаются вновь вот этим неработающим вообще кодом.

Как нам судить обо всём этом букете гипотетических пробелм, если вы старательно все улики замели под ковер? Для чего вы это сделали?

Вам нужно многое понять и изучить прежде чем такая задача станет вам под силу. Судя по постановке вопроса вы очень далеки пока что от понимания основ алгоритмизации и структур данных.
Конечно можно ставить любое уникальное значение любому объекту. Структура данных, которая это позволяет, называется map, а в питоне её реализует тип dict - это словарь, который ставит в соответствие любой объект любому уникальному другому объекту.
Я уверен моего объяснения будет не достаточно вам. Почитайте любую книжку по питону с нуля, например, Марк Лутц пишет приемлемые.
Ещё вам определенно понадобится какая-то БД, например sqlite, или что-то посерьёзнее, например postgres. Базы жанных - это тоже отдельный целый мир, но вам не нужно вних сильно углубляться, однако, одного вопроса, да и вообще вопросов будет недостаточно для нормального понимания.

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

Дело в том, что пока ваши устройства в одной подсети (им выдал адреса один DHCP сервер, это обычно ваш роутер), вы, указав локальный IP другого устройства в сокете, можете создать соединение.
Но если устройства в разных локальных сетях, между которыми не настоен никакой роутинг, то устройства не смогут видеть друг друга. Их адреса будут в разных адресных пространствах.
Это как звонить внутри отеля по внутреннему номеру телефона. Если один из абонентов окажется в другом отеле, то, даже зная его внутренний номер, вы из первого отеля не дозвонитесь ему напрямую по короткому номеру. Придётся пользоваться шлюзом. Вот шлюз - это NAT.
Тут дальше аналогия уже поплывёт, если ещё глубже пытаться её применять.
Прочитайте что такое NAT, что такое белый IP, динамический и статический IP, что такое port-forwarding, сетевая модель OSI, что такое маска подсети и как устроен IP-адрес, как происходит маршрутизация.
Это слишком много инфы, чтобы рассказывать вам об этом в ответе на один вопрос. Вам нужно изучать это самостоятельно.

Павел Панов

про эту строку from collections.abc import Mapping то я незнаю как и куда её нужно вставить

Выглядит так, будто вы немного забегаете вперед в изучении языка.
Прочитайте в любой книге (например Марка Лутца) что такое импорты, как они работают, что за стандартная библиотека collections и что за "Mapping", как он переместился внутри стандартной библиотеки между версиями питона.
Также можно поискать историю версий питна и почитать когда произошел перенос Mapping, можно выбрать нужную версию интерпретатора, под которую написан ваш скрипт.
Скорее всего это какой-нибудь 2.7. более точные выводы делать не по чем.